void sigsegenv()
{
printf("\n\n ********** F D S Message ***********\n\n");
printf("\n\n ********** S E G M E N T A T I O N F A U L T
inside F D S ***********\n\n");
exit(-1);
}
int main(void)
{
...........
..........
signal ( SIGSEGV ,sigsegenv);
..........
..........
}
I think this might give some idea about what is happening.
My signal handler is not catching SIGSEGV always. Some time it is
catching sometimes not. Please let me know what am I doing wrong
>void sigsegenv()
>{
> printf("\n\n ********** F D S Message ***********\n\n");
> printf("\n\n ********** S E G M E N T A T I O N F A U L T
>inside F D S ***********\n\n");
> exit(-1);
>}
>int main(void)
>{
>...........
>..........
> signal ( SIGSEGV ,sigsegenv);
>..........
>..........
>}
You cannot use printf() inside a signal handler.
In standard C, other than calling exit, resetting the signal handler,
or a *very* small number of other things, all you can do is set
a volatile variable of sig_atomic_t .
>I think this might give some idea about what is happening.
>My signal handler is not catching SIGSEGV always. Some time it is
>catching sometimes not. Please let me know what am I doing wrong
What evidence have you found that the handler is not catching SIGSEGV ?
If it is just that the printf() are not occuring, then you might
be encountering the restrictions on what you can do in a handler.
--
All is vanity. -- Ecclesiastes
Thanks,
Madhav.
> Walter Roberson wrote:
>>
>> You cannot use printf() inside a signal handler.
>>
>> In standard C, other than calling exit, resetting the signal handler,
>> or a *very* small number of other things, all you can do is set
>> a volatile variable of sig_atomic_t .
>>
> Could you please tell me about restrictions on signal handlers
He just did.
> or where I can find more info about restrictions on signal handlers?
That's the whole thing.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
>> In standard C, other than calling exit, resetting the signal handler,
>> or a *very* small number of other things, all you can do is set
>> a volatile variable of sig_atomic_t .
>>
> Can I invoke longjmp in signal handler?
Not with well-defined behaviour, no.
JAVA progam calls list of C programs. C programs should return the
status(0, 50 or 100) to JAVA. I somehow want to return the status to
JAVA program if there is a segmentation fault. I don't want to exit
from signal handler
.
>
> Richard Heathfield wrote:
>> vash...@rediffmail.com said:
>>
>> >> In standard C, other than calling exit, resetting the signal handler,
>> >> or a *very* small number of other things, all you can do is set
>> >> a volatile variable of sig_atomic_t .
>> >>
>> > Can I invoke longjmp in signal handler?
>>
>> Not with well-defined behaviour, no.
> Is it possible to return certain value to the calling program from
> signal handler?
No. Signal handlers have the form void handler(int); and thus do not return
a value. You can, however, use the signal handler to modify a file scope
object of type sig_atomic_t.
I think he meant return a value to the program that invoked his C
program, not return a value in to his program. If I read him right, then
calling exit from within the signal handler might be the way to go,
although whether doing exit(99) is valid is system dependant.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Calling exit() in a signal handler is impermissible.
Perhaps you mean _Exit(), a function introduced in C99;
see 7.14.1.1/5. Handlers for signals that were generated
by raise() or abort() are not subject to these restrictions;
handlers for all other signals must respect them.
--
Eric Sosman
eso...@acm-dot-org.invalid
# Can I invoke longjmp in signal handler?
Your program is in a fragile state when the signal handler
is called, and it might not be possible to recover and
continue. On some systems, you can run the program in a
separate process; if it fails, it can report failure and
then exit with recovery. The caller monitors the process
and captures the result or error status.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
TEMPORARILY CLOSED
BE OPENED AFTER FIRST PERIOD
Please look at the list of async-signal-safe functions.
See section "2.4.3 Signal Actions" from the document " 2.4 Signal
Concepts".
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04_03
http://en.wikipedia.org/wiki/Signal_%28computing%29
Regards,
Markus
The above links are Posix, not C. I can't remember the OP saying that
this was only for Posix systems, and if it was then this would be the
wrong group.
A better place to look would be the C standard, a draft of the latest
version being freely available if you search for n1124.pdf.
This document (ISO/IEC 9899:TC2 Committee Draft - May 6, 2005
WG14/N1124) contains the following wording.
Page 20, section "5.2.3 Signals and interrupts":
"...
Functions shall be implemented such that they may be interrupted at any
time by a signal, or may be called by a signal handler, or both, with
no alteration to earlier, but still active, invocations' control flow
(after the interruption), function return values, or objects with
automatic storage duration.
..."
Page 167, section "7.1.4 Use of library functions":
"...
The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static storage duration.
...
161) Thus, a signal handler cannot, in general, call standard library
functions.
..."
There are more descriptions about signal handling in the sections 7.14
and 7.26.6. But the term "async-signal-safe function" is not used in
the specification. I suggest to look at other information sources for
better understanding of the topic "async-signal safety".
- Multithreaded Programming Guide
http://docs.sun.com/app/docs/doc/816-5137/6mba5vpk6?a=view#compat-ix626
http://docs.sun.com/app/docs/doc/816-5137/6mba5vpk4?a=view#gen-ix561
- http://serpentine.com/blog/threads-faq/signals.html
- http://en.wikipedia.org/wiki/Reentrant
http://en.wikipedia.org/wiki/SIGSEGV
Regards,
Markus