1

I debug a ELF32 executable in Ubntu 14, I set gdb breakpoint in main, after i click run, the program generate a new process 13050 and exited, I can't use info register to display value and continue debugging.

how to deal with such situation, thanks


Thanks for the reply, let me give more details, program abc is ELF32 file, it is currently running as process 10220, when i use gdb abc, break main, run, it kills itself ( process 10220) and generate a new process 13050, and this new pid is with another file name xyz. when i display info register or disassembly, whenever i set set follow-fork-mode to parent or child, it says program not exist in gdb. any advice?

in short, abc becomes xyz and abc is deleted by program, any solution?

3
  • Can you supply the executable? i'd like to try it locally and see the errors that pop
    – user22970
    Oct 17, 2018 at 23:18
  • how to supply attachment? in this forum, we can only enter plain text, no photo and attachment
    – Jolin Wong
    Oct 18, 2018 at 6:02
  • just upload it to a file sharing site and put the link in the question. something like filedropper.com
    – user22970
    Oct 18, 2018 at 12:11

2 Answers 2

4

The common way to create a new process in linux (and the only one i know of) is using fork and exec.
When you fork the process, you create a copy of the current process with a new pid, which is passed to the parent (fork caller) - that's how you know how the parent and who the child process are.

To debug child process you can follow the fork.
Note that you can choose to keep either the parent or the child suspended while under the control of gdb but you can only debug one of them with the same instance of gdb.

The usage of it will be (as seen on the link):

set follow-fork-mode [parent/child]

parent = default; you will keep debugging the parent
child = you will start debugging the child

set detach-on-fork [on/off]

on = detach the process you don't debug
off = keep the non-debugee process suspended under the control of the same instance of gdb

1

There should be a small window between the new process start and the first break point hit. So the trick is to collect the new pid with a shell script, feed that pid to a gdb command file and then rapidly repeat the command file during the window.

For example, you can use pidof to get the pid of your program:

echo "attach $(pidof <program>)" > attach_pid

Note that the pidof would pick up a defunct'ed process if there is one.

Under the Unix shell, create an executable file containing the above Unix command. Name it attach.sh.

Next, defined a gdb user defined command:

define a
shell . ./attach.sh
source attach_pid
end

Define a long command name will just slow you down.

When everything is ready, trigger the program, and quickly during the window for re-attach, just hit a and press Enter down until gdb attaches to the process. Note that a return will repeat the previous command and hold on the Enter key will soon generate a rapidly repeated key stroke. Also note that when the new pid is not created yet, the attach_pid just contains "attach " and gives error messages.

1
  • Correction. The pid collection script should be "echo "attach $(pidof program_name)" > attach_pid
    – Remin Lin
    Mar 12, 2020 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.