Need suggestions with Seg fault debugging

I am working on this old c++ program that runs in Linux. It is the worst code I had ever tried to read, and running it with ValGrind gives tons of memory problems. 开发者_C百科

I want to pick off the seg faults one by one, but by the time ValGrind finds the line the code crashes on the damage has been done. This code uses third party libraries as well as home grown libraries. The third party libs can be trusted but not the home grown.

Does anyone have any suggestions on how to find memory corruption that causes a seg fault? I have never had to find seg faults in someone else's code, especially code that was released with no documentation.

Two things that I found out today was, the compiler settings were changed to NOT automatically init. values and the word sized changed from 32 to 64 bit.

I'm at my witts end trying to make any headway, anyone have any deep memory analysis ideas?

thanks

GDB is a good suggestion. You can also use ulimit unlimited (man page) to get the system to dump core files when your program crashes.

That said, the information these tools give you may be misleading when dealing with memory errors. Memory corruption can cause the program to crash in a random place that has little to do with the source of the problem. If you find yourself looking at core dumps or GDB output and wondering how the program could have possibly gotten into that state, it's likely this is what's going on.

In such cases, valgrind is your best friend. Just start at the top of its list of memory errors and fix them one at a time (by which I mean fix one, then rerun, then fix the next, and so on; this is because fixing one error often gets rid of many others) until they're all gone. Then your program will either be more stable or your tools will give you useful information again.

Gdb is probably a better choice than valgrind; when your application (running under gdb) receives a SIGSEGV, gdb will halt execution and generate a stack trace, listing what functions have been called up to that point, and will preserve the state of your program's memory for your perusal. You'll need to build your application with debugging information (-g in gcc) for this to work. Even if the libraries can't be rebuilt, the preservation of the memory of the program will probably be a big help.

The easiest way to debug memory corruption is to catch the corruption as early as possible after it happens, preferably at the exact time - this will allow you to see which thread and method is at fault.

Generally corruption is elusive because failures only occur some time after the damage. Valgrind and other tools are intended to help capture corruption earlier by employing some checks to make sure that buffer overflows and other overlays are caught.

Try looking through the user guides, or try alternative tools to see if you can force a crash or breakpoint close to the corruption.

That said, using a debugger at the natural crash point can reveal information about the corrupted memory, but sometimes it can be a hard slog. Tools like valgrind are invaluable if they don't cause the problem to go away, or cause unacceptably low performance.

See if you can enable debugging features in the memory allocator. glibc's malloc implementation does have some sanity checks which can somehow be enabled.

I once had a case (on an embedded system with a simple chain-based malloc) where the application overwrote the internal data structures of the memory allocator used - resulting in sporadic segfaults on memory allocations.

Thanks everyone, not sure who to give credit to, but valGrind found my problem, seems the code was deleting objects before the save operation which needed them. It took me a little but to get the output for valgrind but it was dead on what was wrong.