My SSH session was terminated abruptly and gdb was running. When I try to attach gdb again to the same process, I get:
ptrace: Operation not permitted.
The ttys:
[root#xxx ~]# who
root pts/0 2017-11-27 03:57 (10.193.26.12)
root pts/1 2017-11-27 04:40 (10.193.26.12)
Question: Which signal should I send to GDB for it to quit gracefully? Are there other ways to solve it?
kill -HUP $gdbpid did the trick for me.
This also kills the inferior when it was invoked by the victim GDB.
However, I do not know whether it also kills the inferior when GDB has been attached to the inferior.
If the parent shell of GDB is still running, then you can attempt to close the pseudo terminal. I usually do it like this:
echo > /dev/pts/0
This forces the SSH parent process to exchange data with the peer. But since the network connection it is gone (as in "the terminal has hung up"), it goes through its shutdown procedure, which includes sending SIGHUP to the process group. The net effect is the same.
Related
I have web daemon and request that makes it fail with SIGSEGV. So i start daemon, attach with gdb, continuing, send request and getting this:
$ gdb attach -p 630066
(gdb) c
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
How to make gdb print stacktrace before killing application? Application do not have subprocesses, just threads.
Thanks.
Your GDB session indicates that you have not attached all threads of the multithreaded process, and some other thread (one you didn't attach) ran into SIGSEGV and terminated the entire process.
Another (somewhat unlikely) possibility is that you are using a very old version of GDB, one which still has this bug in it (the bug was fixed in 2009).
When using gdb -p NNNN you need to be careful and specify correct process id. pgrep daemon-name or ps aux | grep daemon-name should give you a good idea which process to attach.
Just enter backtrace or bt right in the gdb shell after getting SIGSEGV.
To explore stack trace for each separate thread, start with info thread, then choose the thread you need, for example thread 3 and then type bt to see the stack trace for that thread.
I have searched several questions on stackoverflow about debugging SIGTERM, but have not get the information I needed. Perhaps, I am still new to this issue.
My program terminated with the SIGTERM signal without core dump and I donot know how to track this down. My Question is, what is the general way of debugging this issue in GDB?
Thanks.
Although SIGTERM can be sent by the kernel in a few cases, it's almost always sent by another user process. If you run your program under gdb, then when it receives a SIGTERM it will become paused. You can then get some info about the signal by looking at the $_siginfo structure:
(gdb) print $_siginfo._sifields._kill
$2 = {si_pid = 3926, si_uid = 1001}
This is on Linux. It means that pid 3926 sent the signal, and the userid who sent it is 1001.
My program terminated with the SIGTERM signal without core dump
It is expected that if someone sends your program a SIGTERM, then no core dump is produced.
and I donot know how to track this down.
You need to figure out where that SIGTERM is coming from. Someone sends it your program, and the key question is who.
Usually SIGTERM is sent when either you type Control-C in the terminal in which you started the program (correction, that would send SIGINT, not SIGTERM), or you type kill <pid> in some other terminal.
I'm quite new to solaris. I have this problem thats bugging me for sometime now.
I start a process in solaris as
nohup <binary>
I do this so that my process would not get SIGHUP, the process will not terminate even after I exit from my shell.
I tested this out, by exitting from my shell.
It works as expected,the process still runs.
Problem:
When my process is idle for too long, I see the following line in dmesg..
[ID 702911 auth.error] [29069] Run idle timeout reached (32400 seconds)
Then my process gets a SIGHUP, and terminates.
I'm struggling with the following questions...
Which process writes this timeout message in dmesg? How can I find it out?
How come my process still get a SIGHUP despite starting with nohup? Are there any other means for a process to get a HUP signal?
Note: I tried kill -1 <my process id> . Then my process terminates because of the HUP signal.
Can anyone help me on this?
I'm using gdb to connect to a 2.6.31.13 linux kernel patched with KGDB over Ethernet, and when I try to detach the debugger I get this:
(gdb) quit
A debugging session is active.
Inferior 1 [Remote target] will be killed.
Quit anyway? (y or n) y
Bogus trace status reply from target: E22
after that the session is still open, I can keep going on and on with ctrl+d, and the debugger doesn't exit.
I've searched for that message in google and there are just 5 results (and none of them are useful :-/ ).
Any idea of what could it be and how to fix it?
If you cleared all breakpoints on the target and "C"ontinued from the latest breakpoint (assuming that the target code didn't crash, etc.), I think you'll be safe: when running, kgdb won't be talking to your gdb anyway, since if I recall, it only handles the link when stopped (in a breakpoint or exception) awaiting for commands.
A few Ctrl-C in a fast sequence if needed to get control back in gdb, then "q", and that's it.
That's at least my experience when debugging ko's...
I suspect gdb is saying this because it doesn't realize that it is talking to a kgdb rather than to a remote gdb server. I don't imagine kgdb accepting to kill a kernel thread because the debugger was exited, anyway!
Hmmm, afterthought:
You're talking about kgdb 'lite', the one now part of the kernel tree, are you? Because that's the only one I have experience with...
PS on June, 3:
I had never seen the exact message you mentioned until I moved to the 2.6.32 kernel (as part of the migration of my dev and target machines to Lucid). And then, surprise, I ran into it too. Here, it seems to happen in hopeless situations (like a segfault or kgbd seemingly running away after missing a breakpoint or single step). The only cure I have found so far was to pkill ddd (gdb) on the dev machine and reboot the target. But the good news is that the kgdb in 2.6.32 seems to be quite more stable than the one in Karmic (2.6.31).
ctrl + z should help you quit.
Is there a way to stop the inferior without using Ctrl+C (or an equivalent signal sent from another process?) I'm using a windows platform and am managing GDB from another process, so with no notion of signals, it seems that there isn't a good way to break execution of my program when it's free running without any breakpoints.
EDIT FOR CLARITY:
There are 2 processes involved here. There's process A, which is the parent of GDB. GDB is managing a process, but it's on a remote host, and we'll call that process C.
When I tell GDB to "run" it kicks off process C on the remote host and blocks either until a breakpoint is hit, process C encounters an error or a fatal signal, or GDB itself receives an interrupt signal. If working interactively, you would simply press CTRL+C at the GDB command console, which GDB interprets as a SIGINT (somehow), triggering GDB to halt process C. Since I'm actually managing GDB with process A (and not dealing with it interactively at the shell) I can't very well press Ctrl+C, and since windows has no native notion of "Signals" like you have in UNIX, I can't figure out how to interrupt GDB when it's blocking waiting for process C to interrupt or hit a breakpoint.
Did you try to take a look at the remote control protocols? for instance, EMACS uses MI to control GDB, you should check how/if they offer such a ctrl-C mechanism, and how they implement it.
EDIT: it seems to be -exec-interrupt which interrupts the execution.