0

I'm trying to debug a low-level C program in gdb. The program in question is meant to act as a wrapper, launching another process and monitoring/interfering with its memory use.

When I load the program in gdb, everything seems normal (if not ideal) at first. I see the new process fork, and then it hangs. In and of itself, this wouldn't be too strange; likely a deadlock or an infinite loop somewhere in my code.

But if I interrupt and kill the process within gdb, and then run it again within the same gdb session, everything works perfectly fine. It takes about half a second to run and acts exactly as it should.

So my question is: What is gdb preserving between runs of my program? What would change between the first and second execution?

Draconis
  • 3,209
  • 1
  • 19
  • 31
  • Some memory can have some different values. Some HW state might be different (you are saying it is low-level). Many things can happen. – Eugene Sh. Sep 30 '16 at 17:38
  • You're probably accessing some uninitialized variable and thus get into some sort of lock. On second and subsequent runs the data segment of your running process is probably re-used and the same as before, but now as initial values. Watch out for "uninitialized variables" warnings. – tofro Sep 30 '16 at 17:39
  • "But when I interrupt and kill the process" -- *which* process? The one you are debugging, or the one that was forked (or both) ? – Employed Russian Sep 30 '16 at 17:46
  • with out the actual code, we can only guess. My guess is that your code is not properly initializing some variable. When asking a 'run time' question there are certain requriements: post the code, post the actual inputs, post the expected outputs, post the actual outputs. – user3629249 Oct 01 '16 at 18:11

1 Answers1

0

I found the cause, though I still don't understand why gdb acts this way. But I'll post it here in case it's useful to others.

I launched gdb:

gdb --args ./mywrapper testers_exe/tester-2

When run for the first time:

/home/username/mywrapper testers_exe/tester-2

But when killed and run again, it imitated the most recent process, not the arguments it had been given:

/home/username/testers_exe/tester-2 testers_exe/tester-2

Thus it ran the tests without the wrapper, and avoided the wrapper's infinite loop.

Draconis
  • 3,209
  • 1
  • 19
  • 31