CODEWITHSUNDEEP
c++debugginggdb
elkiwy
elkiwy

Reputation: 59

GDB backtrace not showing correct informations

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)

Upvotes: 4

Views: 2816

Answers (1)

Employed Russian
Employed Russian

Reputation: 213879

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.

Upvotes: 5

Related Questions