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.
Related
got some big real time project to deal with (multiple processes (IPCs), multi Everything in short).
My working on process is started as service on Linux. I have the root access.
Here is the problem:
I'm trying to attach to a running proc, tried starting it through/with gdb but the result is the same: it stops the executable once I "touched" it with gdb or sometimes it throws:
Program received signal SIGUSR1, User defined signal 1. [Switching to Thread 0x7f9fe869f700 (LWP 2638)]
of course from there nothing can be done.
Tried:
handle all nostop
attach to launched as service (daemon) or launched as regular proc
started from gdb
thought maybe forking/multi-threaded problem - implemented in the very beginning sleep for 10 seconds - attached to it with "continue"
Guys, all I want it is to debug, hit the breakpoints, etc.
Please help! Share ideas.
Editing actual commands:
1) gdb attach myProcId. Then after reading symbols, I hit "c" which results:
Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x7f9fe869f700 (LWP 2638)]
0x00007f9fec09bf73 in select () from /lib64/libc.so.6
2) If I make the first line 10 seconds sleep in the code, attaching to the process, hit "c", result: it runs, shows info threads, backtrace of main, but never hits the breakpoint (for sure the code runs there - I get logs and different behaviour if I change code there), meaning the process is stuck.
3) All other combinations like gdb path/to/my/proc args list, then start. Where arg list played with different related options gdb gives us.
Maybe worth to mention: process network packets related, timers driven also.
But for me the important thing is a current snapshot on break, i don't care what will happen to the system after timers expired.
Since you mentioned that you are debugging a multiprocessing program, I think the underlying program you have is to set the breakpoint in the correct subprocess.
Try break fork and set follow-fork-mode child/parent. What you want to achieve is have gdb attached to the process that is running the code you want to debug.
Refer to this link.
Another thought is to generate a crash, since you can compile the programe. For example add a int i = *(int*)NULL and that will generate a core dump. You can then debug the core dump with gdb <program> <core dump>. You can refer to this page for how to configure core dump.
Is it possible by any means to brute force momentally pause the execution of an external program? Or something that archieves a similar effect.
I've seen this beforce, a 3rd party software that once came with my Asus laptop, however Im courious on how they managed it.
You can send signals to process. Depending on your operating system, they mean different things. A program which catches a signal may terminate, sleep or continue.
Here is a manual about signals: http://www.cs.cf.ac.uk/Dave/C/node24.html
In short:
Use kill (dont be scared, the functions is just called kill and wont terminate anything on its own) to send a signal to a known process id. You can get process ids in linux with ps aux in terminal. This Linux signal looks promising for you:
SIGCONT 19 /* continue a stopped process */
int kill(int pid, int signal)
a system call that send a signal to a process, pid. If pid is greater than zero, the signal is sent to the process whose process ID is equal to pid. If pid is 0, the signal is sent to all processes, except system processes.
I don't know much about Windows SIGNAL Codes, but it should work similar. Don't know if they are handling the signal codes different then Linux.
There is also: signal (int number, functionPointer) to call a function, if your programm gets a specific signal.
I don't know about bruteforce, but you can probably just set a debug break in a program and that would pause it.
I'm debugging a C++ app for Ubuntu 10.04 that sometimes receives a SIGKILL signal.
I want to catch the signal and stop it from killing the execution, just to see if I can get some useful info of the app's state at that precise moment.
Reading the gdb documentation I found the handle command, so I tried to apply it to the SIGKILL signal:
(gdb) handle SIGKILL stop nopass
Signal Stop Print Pass to program Description
SIGKILL Yes Yes No Killed
So, as I understand this correctly:
stop
GDB should stop your program when this signal happens. This implies the print keyword as well.
print
GDB should print a message when this signal happens.
nopass
GDB should not allow your program to see this signal.
once the SIGKILL signal is emitted, gdb should somehow catch it, print the message, stop the execution and don't let the app kill itself, right?
The problem is that this doesn't happen and the app terminates.
Do you know how could I catch the signal?
Useful Info:
The piece of code that is running when the signal is emitted is executed in another thread.
gdb version: 4.4.3
g++ version: 7.1
From unix signal(7) man page:
The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
So the debugger can set the handler but that doesn't make any sense. The OS directly performs the needed action. If SIGKILL could be handled from application the OS has no chance to terminate a broken application. For that reason SIGKILL is a bit special :-)
I want my program to react on being killed by the 'killall myApplication' command.
So that it can save something and then terminate.
I know this must be done by signal handling but I am not sure which Singal it gets when being killed.
killall or killall -9? Because -9 would mean SIGKILL, which cannot be handled nor masked (your process would be terminated right away in the scheduler, without it having any notion that any signal was sent to it).
Without -9, it would be SIGTERM, which can be handled. Have a look at man signal.
I just came across some code which used the kill system call to send a SIGSEGV signal to an app. The rationale behind this was that this would force the app to core dump and quit. This seems so wrong to me, is this normal practice?
SIGQUIT is the correct signal to send to a program if you wish to produce a core dump. kill is the correct command line program to send signals (it is of course poorly named, since not all signals will kill the program).
Note, you should not send random signals to the program, not all of them will produce a core dump. Many of them will be handled by the program itself, either consumed, ignored, or induce other processing. Thus sending a SIGSEGV is wrong.
GCC Says:
http://www.gnu.org/s/libc/manual/html_node/Termination-Signals.html
POSIX/Unix Says:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html
Yes. kill is somewhat misnamed -- it can send any signal. There are many uses for kill which don't result in the process being killed at all!
If you want to make an application dump it's core from another program, pretty much the only way to do it is via a signal. SEGV would be fine for this. Alternatively you can hook a debugger up to the program and freeze it and view it's registers and such without killing it.
If you want to dump a core from within an application there are nicer ways to do it, like via an assert().
So, no, it's not particularly wrong to send a SEGV to a program. You could also send things like SIGILL for illegal instruction, or a divide by zero signal. It's all fine.
The way to do it in Unix/Linux is to call abort() which will send SIGABORT to current process. The other option is raise() where you can specify what signal you want to send to current process.
Richard Stevens (_Advanced Programming in the UNIX Environment) wrote:
The generation of core is an implementation features of most Unix. It is not part of POSIX.1.
He lists 12 signals whose default action is to terminate with a core (ANSI: SIGABRT, SIGFPE, SIGILL, SIGSEGV, POSIX: SIGQUIT, Other: SIGBUS, SIGEMT, SIGIOT, SIGSYS, SIGTRAP, SIGXCPU, SIGXFSZ), all of them are overwritable (the two signals which aren't overwritable are SIGKILL and SIGSTOP).
I've never seen a way to generate a core which isn't the use of a default signal handler.
So if your goal is to generate a core and stop, the best is to choose a signal whose default handler does the job (SIGSEGV does the job), reset the default handler for the signal if you are using it and then use kill.