5

My understanding is that gdb can monitor the complete state of a running program. Can I save a gdb session that is paused at a breakpoint and resume the session later?

My first attempt was simply generating a core dump in a first gdb session that was paused at a breakpoint and then using the core dump to start a second gdb session.

Saving core file in gdb

This resulted in the following error.

Program terminated with signal SIGTRAP, Trace/breakpoint trap.

So breakpoint information is inserted into the program state, interesting. On my second attempt I did the same but this time I added the same breakpoint to the second session as were in the first session.

Getting gdb to save a list of breakpoints?

Still, I get the same error.

Can I save and restart a gdb session? If so, how?

I don't think this is directly relevant but I'm also getting this warning.

warning: core file may not match specified executable file.

Is gdb simply stating that such a thing is possible in general or does gdb believe this may have happened in the running session? I'm confident that the same executable that produced the core dump is being run under gdb.

Edit: For anyone else who comes along, this question: Save a process' memory for later use? adds to Mats Petersson's answer and links to this article: http://blogs.msdn.com/b/oldnewthing/archive/2004/04/20/116749.aspx which is an interesting read. The linked question also has the suggestion of wrapping the process up in a VM.

Community
  • 1
  • 1
Praxeolitic
  • 22,455
  • 16
  • 75
  • 126
  • Very similar: [c - gdb evaluate function in process core - Stack Overflow](https://stackoverflow.com/questions/8892597/gdb-evaluate-function-in-process-core) (no solution anyway.) – user202729 Mar 10 '22 at 00:55

1 Answers1

4

I doubt that will ever work. Handles for files and any other resources (semaphores, shared memory, serial ports, network connections and lots of other things) that the program has opened/created will be lost when you save the core-file. You can inspect it, but you can't "continue". A core-file is simply a copy of all the memory that original program was using. Anything else is "lost" when the program terminates. In other words, a core-file will only be useful to inspect things later on, but you can't run, step or continue in a core-file debug session. Only "look at things". And if you can't execute, breakpoints won't really work either... ;)

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • The external world is indeed unfortunately designed with a lot of global variables so this can't work in general. Still, it should be possible for simple programs that don't access outside resources. – Praxeolitic Jun 27 '14 at 07:32
  • But since it doesn't work for most programs, why would anyone spend time "fixing" it so that it works to run core-files (and surely your program does more than just calculate things - for example using output?). – Mats Petersson Jun 27 '14 at 07:34
  • Ha, yes it does :( If you could save and load memory state you could get to a point where your program has acquired outside resources and then repeatedly load/save the problematic part which might not be affecting those outside resources. – Praxeolitic Jun 27 '14 at 07:42
  • Or, you could have your program store it's internal state in a restartable form. That's typically how these types of problems are debugged when it's not easy to reproduce the problem... – Mats Petersson Jun 27 '14 at 07:53