6

I start a gdb session in the background with a command like this:

gdb --batch --command=/tmp/my_automated_breakpoints.gdb -p pid_of_proces> &> /tmp/gdb-results.log &

The & at the end lets it run in the background (and the shell is immediately closed afterwards as this command is issued by a single ssh command).

I can find out the pid of the gdb session with ps -aux | grep gdb.

However: How can I gracefully detach this gdb session from the running process just like I would if I had the terminal session in front of me with the (gdb) detach command?

When I kill the gdb session (and not the running process itself) with kill -9 gdb_pid, I get unwanted SIGABRTs afterwards in the running program.

A restart of the service is too time consuming for my purpose.

In case of a successful debugging session with this automated script I could use a detach command inside the batch script. This is however not my case: I want to detach/quit the running gdb session when there are some errors during the session, so I would like to gracefully detach gdb by hand from within another terminal session.

Improve this question
4
  • 1
    Possibly relevant: unix.stackexchange.com/q/31824/291769 Commented Feb 24, 2021 at 20:20
  • 1
    I assume your batch command is running in a loop? Otherwise it should end of its accord. If that is the case one workaround would be to have the loop periodically check for the presence (or absence) of a file. If the file is detected then the loop should exit and detach. Then it would be a simple matter to "signal" gdb by creating (or deleting) the file. Commented Feb 24, 2021 at 20:53
  • @kaylum interesting idea! However, the batch command is simply hanging in the continue and waiting for breakpoints to be matched by the service's actions. So there is no real loop, it's just waiting... Commented Feb 24, 2021 at 21:45
  • Can you show us a stack trace from the SIGABRT? As far as I can tell, the worst case - GDB doesn't remove breakpoints and the target continues after the detach - would result in the target getting SIGTRAP. Commented Feb 25, 2021 at 17:31

1 Answer 1

Reset to default
4

If you run the gdb command from terminal #1 in the background, you can always bring gdb back into foreground by running the command fg. Then, you can simply CTRL+C and detach as always to stop the debugging session gracefully.

Assuming that terminal #1 is now occupied by something else and you cannot use it, You can send a SIGHUP signal to the gdb process to detach it:

sudo kill -s SIGHUP $(pidof gdb)

(Replace the $(pidof gdb) with the actual PID if you have more than one gdb instance)

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

I like the SIGHUP approach, but sadly it did not resolve the SIGABRT signal inside the service. Maybe killing gdb is not even causally related to it, I just observed a pattern here.
@ElectRocnic, I just ran a quick test on my machine, and sending SIGHUP to GDB while the underlying application is running will detach it and SIGCONT the application. Can you explain: "I want to detach/quit the running gdb session when there are some errors during the session". Are these errors in the debugging session?
The error is an unexpected EOF during some io handling on the second API request to the debugged app after I detach gdb during the first request. It might really just be the service itself. I actually believe your answer is correct.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.