Reputation: 5748
Is it possible, under any circumstances, to restore the state of a program to what it was during the generation of a core file?
The reason I ask is that in order to take advantage of gdb's ability to execute functions and so forth you need to have a running instance. Surely it should be possible to produce a mock process of the same executable with the state set to be the contents of the core?
If not what alternatives are there for the sort of situation that made me want to do this in the first place? In this case the back-trace of the core led to a library function and I wanted to replicate the inputs to this function call but one of the inputs is was complex object which could easily be serialized to a string with a function call in a running instance but not so in a core dump.
Upvotes: 14
Views: 2003
Reputation: 4605
In case it's useful to someone, I've implemented a Python module to do just that: call functions in a core file (by emulating the CPU).
It's called EmuCore.
I've successfully used it on very complex functions, example serializing a GStreamer pipeline graph.
Note that it still has important limitations such as:
See README for more info.
Upvotes: 2
Reputation: 213646
It is theoretically possible to do exactly what you want, but (AFAICT) there is no support for this in GDB
(yet).
Your best bet is to use GDB-7.0
and use its embedded python scripting to re-implement the serialization function.
Upvotes: 7
Reputation: 44706
That's what a core file does already? If you load gdb with the original executable and the core file
gdb myprogram.exe -c mycorefile
Then it'll go to the point at where it crashed. You can use all the normal inspection functionality to view the variables, see the stack trace and so on.
Or have I misunderstood your question?
Upvotes: 2