- Forum
- UNIX/Linux Programming
- Best way to debug memory corruption
Best way to debug memory corruption
Hi all,
I'm currently working on a (for me) somewhat larger project, based on SDL. Since yesterday, while running the application, sometimes segfaults occur in internal SDL events, and sometimes even outright memory corruption (double free or corruption, according to libc). A friend running the exact same program does not experience these problems, and when I disable arbitrary parts of the program it does not happen to me either (does not matter which parts I disable though, which leads me to believe the problem is still there, just not causing any crashes).
I have tried to do a backtrace in gdb, but in the case of the segfault this just gives me a stacktrace from some internal SDL thing, and in the case of the memory corruption I just get a bunch of (??) locations.
Obviously, something is going horribly wrong somewhere, but I have no idea how I would go about debugging this, since I have no starting point. So that is basically my question: where do I even start looking in a case like this?
I'm currently working on a (for me) somewhat larger project, based on SDL. Since yesterday, while running the application, sometimes segfaults occur in internal SDL events, and sometimes even outright memory corruption (double free or corruption, according to libc). A friend running the exact same program does not experience these problems, and when I disable arbitrary parts of the program it does not happen to me either (does not matter which parts I disable though, which leads me to believe the problem is still there, just not causing any crashes).
I have tried to do a backtrace in gdb, but in the case of the segfault this just gives me a stacktrace from some internal SDL thing, and in the case of the memory corruption I just get a bunch of (??) locations.
Obviously, something is going horribly wrong somewhere, but I have no idea how I would go about debugging this, since I have no starting point. So that is basically my question: where do I even start looking in a case like this?
Get SDL with the debug symbols included (might have to build it yourself) and run it under valgrind.
Given that the problem is probably in your code rather than in SDL, you could probably just build your code with debug symbols included and under gdb and valgrind, the stacktrace into your code will have helpful diagnostics.
Given that the problem is probably in your code rather than in SDL, you could probably just build your code with debug symbols included and under gdb and valgrind, the stacktrace into your code will have helpful diagnostics.
Last edited on
I finally had the time to delve into valgrind, and with the help of that tool the problem was solved. Thanks for the recommendation!
I think I have got similar problems. I'm thinking of using valgrind for that, If you could share your learning experience or hurdles with valgrind would be a great help. Like some good start up tutorial you find helpful and any other details you would like to share
To use valgrind:
1) Get valgrind.
2) Build your program with debugging symbols ( commonly -g compiler switch).
3) Run program using command line:
1) Get valgrind.
2) Build your program with debugging symbols ( commonly -g compiler switch).
3) Run program using command line:
valgrind nameOfProgramToRun
Topic archived. No new replies allowed.