By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,706 Members | 1,305 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,706 IT Pros & Developers. It's quick & easy.

SIGSEGV Handling

ilikesuresh
P: 47
Hi,
please any one explain how to handle sigsegv signal with example.....

Thanks
Sep 21 '07 #1
Share this Question
Share on Google+
5 Replies

ruskalym
P: 65
Hi!

How would you like to handle it?

Do you want to catch it inside a program you wrote or to catch another program's signal?
Sep 21 '07 #2

ilikesuresh
P: 47
In the same program i need to catch the signal
Sep 21 '07 #3

ruskalym
P: 65
Here is a tiny code listing that catches the SIGSEGV signal :

Expand|Select|Wrap|Line Numbers
  1. void my_action(int sig)
  2. {
  3.    printf("Caught signal\n");
  4. }
  5.  
  6. int main()
  7. {
  8.    struct sigaction sa;
  9.  
  10.    memset(&sa, 0, sizeof(struct sigaction));
  11.    sa.sa_handler = my_action;
  12.    sigemptyset(&sa.sa_mask);
  13.    sigaction(SIGSEGV, &sa, NULL);
  14.  
  15.    while (1);
  16.  
  17.    return 0;
  18. }
We first create a sigaction structure and set its handler to my_action.

If a SIGSEGV is caught after the sigaction() call, my_action() will be called.

However, the program will crash or call my_action() in an infinite loop if the SIGSEGV originates from program's memory violation.
Sep 21 '07 #4

P: 1
Hi,

Need assistance regarding SIGSEGV handling.

I tried the above example and suprisingly program enters into infinite loop in signal handler function.

I want the control to come back to main from my_action() api without killing the program. Is it possible ? If possible please send me the answer.

Thanks,
Regards,
Janardhan.
Feb 26 '08 #5

P: n/a
SIGSEGV is a synchronous signal. That mean it happens as part of current executing instruction. In general we do not handle SIGSEGV. If you provide your handler for these, handler will be executed and then your faulted instruction is tried again. This is where asynchronous signals differ. This is expected behavior.
Oct 15 '10 #6

Post your reply

Sign in to post your reply or Sign up for a free account.