I have gdb running on cpp application process on remote machine, and accidenttly close terminal. How do i get into this gdb shell again?
$ pidof application
12345
$ pidof gdb
23456
gdb was started like "gdb --pid=12345" which is attached to process.
How do I get back into gdb shell from external shell. Is there any way like
"enter-gdb-shell with pid 23456"
reptyr does what you want: attach a terminal to a running process.
Related
I am trying to write a script to launch OpenOCD in the background, and then launch and instance of GDB connected to my OpenOCD server. This mostly works, except that as soon as I type the interrupt character to halt the target I am debugging my OpenOCD server exits. It appears that OpenOCD is receiving SIGINT.
I have tried to separate OpenOCD from GDB in a number of different ways, at this point my script looks like this:
#! /bin/sh
trap '' SIGINT && nohup sh -c "trap '' SIGINT & openocd -f openocd-jlink.cfg < /dev/null" &
OPENOCD_PID=$!
arm-none-eabi-gdb -ex "set architecture armv6-m" -ex "target extended-remote localhost:2331" obj/main.elf
kill $OPENOCD_PID
I'm pretty sure that this should be very overkill yet OpenOCD still exits as soon as I type the interrupt character in GDB. If I run the same commands directly from my shell (not as part of script) everything works as expected. It works even if I just run openocd -f openocd-jlink.cfg & followed by GDB, no separate shell, nohup or trapping of SIGINT is required.
I'm hoping that someone might have an idea of what I can do in my script to prevent the SIGINT in GDB from reaching OpenOCD. Maybe there is some way to daemonize entirely from shell? I have read a lot of answers here about more generic issues with SIGINT in scripts, so I have a feeling this might be something specific to OpenOCD and GDB.
I have managed to solve this issue by using setsid. The working version of the script is:
#! /bin/sh
setsid openocd -f openocd-jlink.cfg -l /dev/null &
arm-none-eabi-gdbm" -ex "target extended-remote localhost:2331" obj/main.elf
killall openoc
Since I want the script to work on macOS as well as Linux and macOS does not ship with a setsid I ended up using Python to launch OpenOCD, which looks like this:
subprocess.Popen(["openocd", "-f", "openocd-jlink.cfg", "-l", "/dev/null"], preexec_fn = os.setsid)
I am trying to debug GDB itself and dealing with a Ctrl+C signal problem that is sent from another terminal.
I run GDB to be debugged in terminal 1 in TUI mode. Right after, I open another terminal 2 and find the PID number of the GDB that runs on Terminal 1. Then attach that process to debug.
In Terminal 1
$ build-gdb/gdb/gdb -tui ./build/output.elf -tty=$TTY
In Terminal 2
$ ps -elf | less
$ sudo gdb -p PID_NUMBER-tty=$TTY -tui
The problem is when I hit Ctrl+C to stop GDB in terminal 1, GDB runs on Terminal 2 stops. GDB in Terminal 1 does not responds to ^C command at all. I tried to use -tty parameter and get the current TTY, but id did not solved the problem. GDB uses readline GNU library, but i should be configure terminal and its input properly.
Any idea?
You can use
handle SIGINT pass
to instruct GDB to pass the signal to the inferior. See Signals in the GDB manual. The nostop argument could be useful in this situation, too.
I'm doing my project and I need to log keystrokes system wide in macOS. So, I turned over to GitHub and found Swift-Keylogger. The only problem is I can't quit the Terminal while the program is still running.
Is there any way to not to run this in terminal or closing the terminal window instead of creating a mac app like here.
Note: There are some mac app style executables in github but they are not providing the output I want and some need additional permissions.
Instead of running the executable like ./Keylogger use nohup ./Keylogger &.
You can quit the Terminal after executing the command.
To kill the Keylogger, run ps -e | grep "Keylogger" to get pid and kill -9 pid.
P.S. I thought of adding it as well as running at startup but I'm too lazy to update the repository.
Is there a way to exit from gdb connnection without stopping / exiting running program ? I need that running program continues after gdb connection closed.
Is there a way to exit from gdb connnection without stopping / exiting running program ?
(gdb) help detach
Detach a process or file previously attached.
If a process, it is no longer traced, and it continues its execution. If
you were debugging a file, the file is closed and gdb no longer accesses it.
List of detach subcommands:
detach checkpoint -- Detach from a checkpoint (experimental)
detach inferiors -- Detach from inferior ID (or list of IDS)
Type "help detach" followed by detach subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
Since the accepted (only other) answer does not specifically address how to shut down gdb without stopping the program under test, I'm throwing my hat into the ring.
Option 1
Kill the server from the terminal in which it's running by holding Ctrl+c.
Option 2
Kill the gdb server and/or client from another terminal session.
$ ps -u username | grep gdb
667511 pts/6 00:00:00 gdbserver
667587 pts/7 00:00:00 gdbclient
$ kill 667587
$ kill 667511
These options are for a Linux environment. A similar approach (killing the process) would probably also work in Windows.
I have two terminals open (within tmux). In the first, I type:
$ tty
/dev/pts/4
And in the second
$ gdb brokenprogram
(gdb) tty /dev/pts/4
This successfully redirects the output of the process being debugged to the first terminal. However, when I type in the first terminal, bash and brokenprogram are competing to read input. How can I stop bash from listening to any further keypresses?
I think the suggestion to run sleep so the shell doesn't access the tty is fine, but an alternative is to use gdbserver.
On /dev/pts/4:
$ gdbserver localhost:12345 brokenprogram
Process brokenprogram created; pid = 9134
Listening on port 12345
On the other terminal:
$ gdb brokenprogram
(gdb) target remote localhost:12345
Remote debugging using localhost:12345
<gdb chatter that the process is stopped at _start()>
(gdb) continue
And then you can interact with brokenprogram on /dev/pts/4.