C++ How to interpret gdb backtrace log in Ubuntu

Question

I have written a fairly large C++ program. As a preface, the program runs well every time save for an exiting error, free() invalid pointer usually leading to a core dump; besides this, the program does what I need it to do every time. The program is free of any pointer objects or initialization; despite the program being very long(some 3000 lines), it is rather simply written(mostly int variables, and some 2D vector arrays). My first thought was that some FOR loop was writing beyond vector bounds so I ran Valgrind mems check to see if there is any memory leaks but Valgrind returned a clean report. My next inclination was to use gdb and see if it returned any errors. It did return a SEGABRT so I backtraced it, and gdb returned the following,

> #0  0x00007ffff7018c37 in __GI_raise (sig=sig@entry=6)
>     at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff701c028 in __GI_abort () at abort.c:89
> #2  0x00007ffff70552a4 in __libc_message (do_abort=do_abort@entry=1, 
>     fmt=fmt@entry=0x7ffff7167310 "*** Error in `%s': %s: 0x%s ***\n")
>     at ../sysdeps/posix/libc_fatal.c:175
> #3  0x00007ffff706182e in malloc_printerr (ptr=<optimized out>, 
>     str=0x7ffff716345e "free(): invalid pointer", action=1) at malloc.c:4998
> #4  _int_free (av=<optimized out>, p=<optimized out>, have_lock=0)
>     at malloc.c:3842
> #5  0x000000000040f152 in __gnu_cxx::new_allocator<int>::deallocate (
>     this=0x7fffff85cf60, __p=0x6c1f40)
>     at /usr/include/c++/4.8/ext/new_allocator.h:110
> #6  0x000000000040ef54 in std::_Vector_base<int, std::allocator<int> >::_M_deallocate (this=0x7fffff85cf60, __p=0x6c1f40, __n=32)
>     at /usr/include/c++/4.8/bits/stl_vector.h:174
> #7  0x000000000040ebc2 in std::_Vector_base<int, std::allocator<int> >::~_Vector_base (this=0x7fffff85cf60, __in_chrg=<optimized out>)
>     at /usr/include/c++/4.8/bits/stl_vector.h:160
> #8  0x000000000040e928 in std::vector<int, std::allocator<int> >::~vector (
>     this=0x7fffff85cf60, __in_chrg=<optimized out>)
>     at /usr/include/c++/4.8/bits/stl_vector.h:416
> #9  0x000000000040e3b5 in main ()

I suppose my question is this. How do I interpret this backtrace? I only see the last stack #9 calling main function but it has no other errors associated with it. The stack errors #0-8 I assume are failures in the called libraries? Is there a way or some options in gdb that I can call to help pinpoint the error and where it is originating from in this backtrace? I am fairly new to using gdb in general so any suggestions would be most appreciated.

Edit Sample Code:

for(int k = 4; k < 7; k++)
{
    if(TFNCWS[k] == 1)
    {
        TFNCWS[k] = 0;
        TIM[k] = 1;
    }
}

Answer 1

How do I interpret this backtrace?

Very simply: your program crashes while destructing a vector, declared somewhere in your main function.

The most likely cause is stack corruption.

I ran Valgrind mems check to see if there is any memory leaks

Memory leaks have nothing to do with your problem, and Valgrind is exceedingly weak at detecting stack overflows.

You should try Address Sanitizer (available in recent GCC and Clang). Chances are it will point you straight at the problem.