Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to properly find a Heisenbug?

Tags:

c++

c++14

After some resource modification (an image), my program has been getting random crash (0xC0000005). I know these come from bad memory management, but I can't find where it comes from, because of two reasons: first, I don't use alot of pointers or dynamicaly allocated variables manually (I mean I use the standard library which does it for me), and second, the bug doesn't happen when I'm debugging with gdb (but it does appear when running the debug build, without gdb).

I tried to pinpoint the bug with sd::cout, but I still can't find it due to the way my program is written. I double, triple-checked the pointers and dynamic arrays I use, still can't find it. For info, debug is compiled with "-g -std=c++14", but no "-O2". I use Code::Block with a 64bit MingW with GCC 5.1.0 and gdb 7.9.

So, I read alot of things of those type of bug (0xC0000005) and Heisenbug, but I don't know understand how to deal with it, I don't know what to try now.

I'd show you the code, but it's spread across 30 files. If you really want to see, it's here on github though.

Also, you won't be able to test it out because I didn't upload the resource files (I don't own them).

So do you have any suggestion for me to be able to find where the bug comes from ?

like image 816
Corentin M Avatar asked Dec 11 '15 22:12

Corentin M


1 Answers

Start the program, then attach gdb; if you start a program under a debugger Windows switches to the debug heap, which usually can help to detect memory usage problems, but sometimes hides Heisenbugs (because it actually changes the default content of uninitialized memory).

By starting the program first and then attaching the debugger you avoid this discrepancy between a "normal" run and a "debug" run, thus you should be able to catch the access violation directly in the debugger.

Aside from the "manage to reproduce the crash under a debugger" thing, you may want to use various tools that can help you to detect the bug earlier; recent g++ versions provide tools such as the address sanitizer and the debug STL, which helped me to pinpoint many serious bugs that went unresolved for years.

Incidentally, even when a program is not already under a debugger, Windows offers the possibility to start one of the registered ones in case of a crash, in the usual crash dialog there should be a "Debug" option. It doesn't seem that it's possible to register gdb between the system debuggers, but if you install Visual C++ Express or the Debugging tools for Windows you should at least have some kind of debugger always ready for these occasions (using them to debug g++-generated executables with dwarf debug information instead of PDB is a whole other can of worms, though).

like image 80
Matteo Italia Avatar answered Sep 28 '22 12:09

Matteo Italia