tags:

views:

443

answers:

2

I have a core dump sitting on disk, created by an app that failed an assert and aborted. The app was compiled in debug mode on Linux/g++. I suspect that in the stack frame at the top of the stack, my this object has been delete'd (I think this is no longer a valid ptr). However it could take days or longer to reproduce this abort.

Is there a way for me to query the new/free implementation from within gdb (or elsewhere) and verify whether a given memory address is valid allocated memory? In other words, can I see if my this is still allocated, or if it has likely been deleted'd? It'd have to be static, since I just have a core dump and not a running executable.

+1  A: 

It's not impossible, but it's pretty darn close, if you're using the standard malloc/free/new/delete calls. If you think you could reproduce the problem again in a few days, that's probably the faster route.

What you can do in the meantime is prepare for the next incident so you can better analyze it.

Dmalloc is a free utility you can use that replaces the default C/C++ memory functions with versions that can perform extra checks and bookkeeping.

LD_PRELOAD=libdmalloc.so your_program_here will run the program with dmalloc and you can set flags to wipe memory so you'll know whether any memory has been deleted.

Shmoopty
A: 

The core dump contains the full state of the program at the time of exit (including the state of the processes memory allocations). However you would have to know deeply how memory allocation works to figure out if the object is still valid or not. However inspecting the program state in the debugger may lead to the discovery of the problem even without knowing the exact memory allocation strategy. Did you check the stacks of all threads for obviuous "bad" values? They may give you very valuable hints themselves.

Another very good idea would be to run your app in valgrind.

lothar