Debugging heap/stack corruption for apps built with mingw-w64

Help
asiga
2014-01-14
2014-01-15
  • asiga

    asiga - 2014-01-14

    Hi,

    I've hit a difficult to debug issue on a big application (it uses wxWidgets, OpenGL,...,
    so yes, it's a big one). I cannot use Purify because it doesn't work with mingw-w64 executables. Valgrind neither because I need to debug it on (real) Windows. Running with gdb I get a corrupted stack trace which doesn't help (and I might also be hitting an internal gdb bug here, from the output I get).

    Tried with Dr Memory but the application exits in mysterious way (harmless errors are output but in the instant of truth, the app quits and Dr Memory doesn't show any error).

    I considered Memory Validator, but I've read statically linked executables don't work, and I'm statically linking (just for the purpose that I don't need to provide mingw DLLs to the end-user).

    Then I tried to debug the UNIX version on OSX with ElectricFence (I said I'm using wxWidgets, so it's a multiplatform app), and ElectricFence helped me fix some minor unrelated mistakes, but the UNIX version runs fine: no heap corruption,
    stack is fine, and ElectricFence runs super-happy.

    What would you do? What's the most powerful ever created memory debugging tool for mingw-w64?

    TIA,

     
  • asiga

    asiga - 2014-01-15

    Well, this was really painful. I found the culprit, but after much pain, because to make things worse, it only appeared in optimized builds (it was very helpful that gcc lets you add debug information into optimized executables).

    The culprit: Some functions declared as (plain) extern were being passed as callbacks to the GLU tessellator (which expect them to be __stdcall). This made the GLU tessellator code trash its internal data, and, in the end, trash the program stack.

    No memory debugger was able to find this bug. I understand it might be very hard or even impossible to write a runtime debugger that catches these bugs, but...

    ... is there any gcc flag which would never allow non-matching calling conventions on Windows? It would have saved me three days of debugging with several memory debuggers... three days!!!

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks