GDB backtrace not showing correct informations - c++

Question

I'm learning how to debug with gdb on my mac and after finding a segmentation fault I wanted to use it to learn.
I'm using gdb 8.0.1 and gcc 7.2.0 both from homebrew, I'm compiling with -ggdb and running gdb directly from my makefile through gdb -ex run ./main.
I open the game, I open a menu inside it, and when I try close it it crashes because I do this in WindowsObject.cpp :
WindowObject_CraftingGrid::~WindowObject_CraftingGrid(){
for (unsigned i = 0; i < gridSlots_.size(); i++) {
for (unsigned j = 0; j < gridSlots_[0].size(); i++) { //i++ instead of j++, this leads to the crash
delete gridSlots_[i][j];
}
}
}
Gdb says:
(gdb) bt
#0 0x0000000100023a80 in WindowObject_Image::Draw (this=0x300000000) at src/WindowObjects.cpp:620
#1 0x0000000100023ae2 in WindowObject_Image::setImage (this=0x100a9e980, img=0x0) at src/WindowObjects.cpp:629
#2 0x000000010001d5f7 in WindowMain::AddSection (this=0x100a04ce0, n=28672) at src/Window.cpp:263
#3 0x0000000100033765 in LoadLibrary () at src/main.cpp:781
#4 0x0000000100030b25 in DrawGUI () at src/main.cpp:465
#5 0x0000000100031534 in DrawGUI () at src/main.cpp:501
#6 0x00000001006eae27 in ?? ()
#7 0x0000700001875ef0 in ?? ()
#8 0x00007fff40b796d8 in ?? ()
#9 0x0000000000000000 in ?? ()
And this is totally wrong because it leads to nothing useful to solve the bug because it does not point to the right objects and lines.
I discovered this bug from visual studio on my windows machine because the call stack there was quite clear:
project.exe!std::vector<std::vector>WindowObjects_Slot * //Other stuff
project.exe!WindowObject_CraftingGrid::~WindowObject_CraftingGrid() Line 348
project.exe!WindowMain::~WindowMain() Line 234
project.exe!KeyPressed(int KeyCode) Line 566
project.exe!gameloop() Line 181
project.exe!main(int argc, char ** argv) Line 321)

Answer 1

And this is totally wrong
No, it's not: it's where your application actually crashes on this platform.
because it leads to nothing useful to solve the bug
You have a heap corruption bug. Heap corruption bugs are like that: your application may crash some time after heap corruption, in an arbitrary place.
In addition, the stack trace is not useless: it tells you that this == 0x300000000, which is not a reasonable value for this, and therefore you are looking at some kind of heap corruption.
There are many ways to debug similar problems: debug malloc, Address Sanitizer and Valgrind among them.
Building with -D_GLIBCXX_DEBUG enables debugging mode in GCC STL, and would likely also point you straight at the bug.