I have a problem with signal handler algorithm in linux. My code is hanging ( It is continuously looping inside the signal handler) . I am pasting my code here...
Please provide me some help regarding this. I googled many places and wrote this code.. but doesnt seem to be working without exit(0).. but i guess this is not the right way. What could be wrong?
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
struct sigaction oldHandler;
void myHandler(int sig, siginfo_t *siginfo, void *context) {
// if i have not written any code inside this function, the program will give a feel of hang( this functions is getting continuously called
if(siginfo->si_code == SEGV_MAPERR)
{
write(1,"address not mapped to object",strlen("address not mapped to object"));
}
else if (siginfo->si_code == SEGV_ACCERR)
{
write(1,"invalid permissions for mapped object",strlen("invalid permissions for mapped object"));
}
write(1,"\n",1);
// exit(0); if this exit(0) is not present, program will get continuous calls to this signal handler
return;
}
int main(int argc, char *argv[]) {
/* Install mySignalHandler for SIGSEGV */
struct sigaction sigAct;
int status = 0;
char *addr = NULL;
sigAct.sa_handler = 0;
sigAct.sa_sigaction = myHandler;
sigfillset(&sigAct.sa_mask);
sigAct.sa_flags = SA_SIGINFO;
status = sigaction(SIGSEGV, &sigAct, &oldHandler);
if (status != 0) {
perror("Failed to install handler for signal SIGSEGV");
exit(1);
}
#if 1
/* This will invoke the signal handler */
// addr = malloc(strlen("Hello"));
strcpy(addr,"Hello");
printf("%s\n",addr);
#endif
printf("Returning from main\n");
return 0;
}
Your code keeps getting SIGSEGV. Since you don't resolve the problem that caused the SIGSEGV, when your handler returns your code just gets another SIGSEGV.
hi,
thanks.. but how does it keep on getting signal 11?
the strcpy() function will get one signal 11, that i can understand..
Do you mean internally(deep inside strcpy()) it is getting signal 11???
also could you please tell me how to avoid this subsequent signals. Because in sig handlers, i cannot do a lot of work or can call malloc() or any other unsafe function. So how do i avoid the subsequent signal 11's?
I tried commenting the printf() after strcpy() but it is still getting infinite number of signal 11....
Most unix implementations have the equivalent of an interrupt stack.
SIGSEGV is generated by the OS, not by your process.
TOP:
Your code tries to access out-of-bounds memory. The OS does not allow this, it raises SIGSEGV instead. SIGSEGV signal calls your signal/interrupt handler on the interrupt stack. As soon as the signal handler exits, the interrup stacks pops the offending instruction off the interrupt stack. Then the old, exact same, offending machine code instruction resumes right where it left off - So
goto TOP
Signals do not cure problems. They alert you to them.
Thank you for the explanation.
It means the same instruction which would have caused trouble keeps on getting to the execution point and OS alerts me infinite times.
So , this would be the case for all SIGSEGV/SIGBUS cases. Then can anyone tell me what could be the best possible algorithm to handle these types of signals.
Would it be anything like
Check the reason for signal.
Alert user/ get information for debugging
Terminate execution from the signal handler itself.(if i return from sig handler, it means that i am eligible for another signal, isn't it?)
On some platforms, you won't get infinite recursion: the process shall be terminated. But anyway you have to account of that possibility, as you experienced it hardly. The way I usually deal with signal caused by HW exception in signal handler is:
log whatever I can to locate the problem post-mortem. This could be for instance the address of the IP (Instruction Pointer) that generates the exception, or better of stack frame, or even fire a debugger (if you can afford it). Make sure however to only call functions that can be safely used in signal handlers (POSIX calls them async-signal-safe).
restore the default signal handler for the signal caught.
return from the handler.
The return from the handler triggers again the exception, but that time the default signal handler is called, causing normally process termination (and usually, a core dump too).
