Sometimes when I am debugging I get message like this.
Program received signal SIG44, Real-time event 44.
What does it means?
Thank you.
EDIT :
Platform is linux
A signal is a message sent by the kernel to a process in order to notify the process that event of some kind has occurred in the system.
Usual signals on linux are for example SIGINT (value 2, interrupt from keyboard) or SIGKILL ( value 9, kill a program).
Signals are received either when the kernel detects a system event (like division by zero is SIGFPE, value 8) or when a process invokes the kill() function to explicitly tell the kernel to send a signal to a process (or to the process itself that called the kill() ).
A signal can often be caught by the process in order to do something.
So to answer to your question, the code is most likely calling the kill() function and sending it a signal with value 44 when something happens. Since you are getting that message, it means that the process has received the signal and is going to exit or do what is written in the code in case that signal comes.
Unlike standard signals, real-time
signals have no predefined meanings:
the entire set of real-time signals
can be used for application-defined
purposes. (Note, however, that the
LinuxThreads implementation uses the
first three real-time signals.)
Source for the quote here
The GNU C++ library uses SIG44 to awaken sleeping threads when signalling condition variables.
Related
In a debugging session, when the deugger wants to set a breakpoint, it replaces an instruction by int3. When the Target process reach this instruction, the process stops. I have read that a signal is send at this time. But i did not manage to capture this signal (i wrote my own mini debugger for testing). Who send this signal ? The kernel? And who is the receiver?
I had to put a wait() fonction juste after the ptrace_cont. Do you think this is this wait function that catch the signal in order to notify the debugger that the process reach a break point ?
When the Target process reach this instruction, the process stops.
That's not quite accurate. When the trap instruction (0xCC on x86) is executed, the processor notifies the OS. On UNIX, the OS checks to see whether the process is being ptraced by somebody.
If no, the SIGTRAP signal is delivered to the application, which usually results in process being killed (but you can catch and handle the signal in the application).
If there is a ptraceer (usually a debugger), then the signal is not delivered to the application. Instead, debugger's wait is unblocked to notify the debugger that the inferior has changed state. The debugger then looks at where the inferior process stopped, discovers that it did so because of a breakpoint, and handles the situation as appropriate (let's you examine the inferior, or resumes it if the breakpoint is conditional and current conditions don't match, etc.)
In a system running Linux 2.6.35+ my program creates many child processes and monitors them. If a child process dies I do some clean-up and spawn the process again. I use signalfd() to get the SIGCHLD signal in my process. signalfd is used asynchronously using libevent.
When using signal handlers for non-real time signals, while the signal handler is running for a particular signal further occurrence of the same signal has to be blocked to avoid getting into recursive handlers. If multiple signals arrive at that time then kernel invokes the handler only once (when the signal is unblocked).
Is it the same behavior when using signalfd() as well? Since signalfd based handling doesn't have the typical problems associated with the asynchronous execution of the normal signal handlers I was thinking kernel can queue all the further occurrences of SIGCHLD?
Can anyone clarify the Linux behavior in this case ...
On Linux, multiple children terminating before you read a SIGCHLD with signalfd() will be compressed into a single SIGCHLD. This means that when you read the SIGCHLD signal, you have to clean up after all children that have terminated:
// Do this after you've read() a SIGCHLD from the signalfd file descriptor:
while (1) {
int status;
pid_t pid = waitpid(-1, &status, WNOHANG);
if (pid <= 0) {
break;
}
// something happened with child 'pid', do something about it...
// Details are in 'status', see waitpid() manpage
}
I should note that I have in fact seen this signal compression when two child processed terminated at the same time. If I did only a single waitpid(), one of the children that terminated was not handled; and the above loop fixed it.
Corresponding documentation:
http://man7.org/linux/man-pages/man7/signal.7.html "By contrast, if multiple instances of a standard signal are delivered while that signal is currently blocked, then only one instance is queued"
http://man7.org/linux/man-pages/man3/sigwait.3p.html "If prior to the call to sigwait() there are multiple pending instances of a single signal number, it is implementation-defined whether upon successful return there are any remaining pending signals for that signal number."
Actually the hassle-free way would be the waitfd functionally that would allow you to add a specific pid to poll()/epoll(). Unfortunately, it wasn't accepted to Linux years ago when it was proposed.
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 am a newbie and have basic understanding of linux.
Whenever the kernel encounters a signal for a particular process, first it checks the signal handler table in the process control block(PCB) of the particular process. If the signal handler is registered it calls the function. if the flag is SIG_DEFAULT then it calls the signal handler registered in the global signal table of kernel. If the flag is SIG_IGNORE then kernel just ignores the signal for the particular process.
All signals have default signal handlers already registered in signal table by kernel.
I just want to know how a process can change the flag from SIG_DEFAULT TO SIG_IGNORE. Please explain the mechanism(either using system call or changes in the signal table or PCB). Next time when the signal is again captured what optimizations does the kernel do.
Call the signal function. Note that some signals may not be ultimately ignoreable.
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.