Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Signal dispositions

Reply
Thread Tools

Signal dispositions

 
 
Leet Jon
Guest
Posts: n/a
 
      11-02-2007
Hi what's the reason for having the default disposition for SIGSEGV,
SIGFPE, SIGBUS etc to be terminating the program, when these signals can
just be ignored by the program? Many programs crash with SIGSEGV -
they'd be much less flakey if the default was to try to carry on.

~Jon~

 
Reply With Quote
 
 
 
 
Joachim Schmitz
Guest
Posts: n/a
 
      11-02-2007
"Leet Jon" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> Hi what's the reason for having the default disposition for SIGSEGV,
> SIGFPE, SIGBUS etc to be terminating the program, when these signals can
> just be ignored by the program? Many programs crash with SIGSEGV -
> they'd be much less flakey if the default was to try to carry on.

Carry on with corrupted data? No, that's not a sane default.

Bye, Jojo


 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      11-02-2007
Leet Jon <(E-Mail Removed)> writes:
> Hi what's the reason for having the default disposition for SIGSEGV,
> SIGFPE, SIGBUS etc to be terminating the program, when these signals can
> just be ignored by the program? Many programs crash with SIGSEGV -
> they'd be much less flakey if the default was to try to carry on.


The default handling for signals is implementation-defined (C99
7.14p4), so you might get better answers in comp.unix.programmer than
here in comp.lang.c. (I just noticed the cross-post; I've set
followups to comp.unix.programmer.)

However, letting a program continue running by default after a
catastrophic data-corrupting failure would not be a good idea. If a
program dies immediately after "an invalid access to storage" (which
is all the C standard says about SIGSEGV), then you have a good chance
of diagnosing and correcting the problem before putting the code into
production. If the error is ignored, the program will very likely
continue to corrupt your data in subtle ways; tracking it down and
fixing it is going to be difficult if the error occurs at a customer
site, or even during an important demo.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Leet Jon
Guest
Posts: n/a
 
      11-02-2007
On 2 Nov 2007 at 19:10, Keith Thompson wrote:
> However, letting a program continue running by default after a
> catastrophic data-corrupting failure would not be a good idea. If a
> program dies immediately after "an invalid access to storage" (which
> is all the C standard says about SIGSEGV), then you have a good chance
> of diagnosing and correcting the problem before putting the code into
> production. If the error is ignored, the program will very likely
> continue to corrupt your data in subtle ways; tracking it down and
> fixing it is going to be difficult if the error occurs at a customer
> site, or even during an important demo.


I believe you are completely wrong on this point. Very often a SIGSEGV
will be caused by (say) a single bad array access - the consequences
will be highly localized, and carrying on with the program will not
cause any significant problems.

Who wants their customer to run their program and have it just crash
with a segfault? That hardly comes across as professional. Better to try
your best to carry on and weather the storm than to just dump the user
with a crash.

I can understand that for debugging purposes you might want to have
SIGSEGV etc. generate a core file, but in production code the default
should be for these signals to be ignored.

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      11-02-2007
Leet Jon wrote:

> Hi what's the reason for having the default disposition for SIGSEGV,
> SIGFPE, SIGBUS etc to be terminating the program,


That's not specified by the C Standard but is a matter for
implementation.

> when these signals can just be ignored by the program?


Do you routinely ignore early signs of serious illness? No? Then why
should one ignore signs of erroneous conditions in a program and allow
it to result in erroneous output?

> Many programs crash with SIGSEGV - they'd be much less flakey if the
> default was to try to carry on.


Try a little demo yourself. Write a data processing program of any kind
and deliberately code in a bounds violation condition. Then make sure
to catch SIGSEGV and continue execution. Observe if the end result is
what the program is supposed to do.

Signals indicate exceptional situations that the program must imminently
address. Ignoring a signal, regardless of whether it's because of
program error or a normal but exceptional condition, is only likely to
break the program further.

 
Reply With Quote
 
Al Balmer
Guest
Posts: n/a
 
      11-02-2007
On Fri, 2 Nov 2007 21:16:31 +0100 (CET), Leet Jon <(E-Mail Removed)>
wrote:

>On 2 Nov 2007 at 19:10, Keith Thompson wrote:
>> However, letting a program continue running by default after a
>> catastrophic data-corrupting failure would not be a good idea. If a
>> program dies immediately after "an invalid access to storage" (which
>> is all the C standard says about SIGSEGV), then you have a good chance
>> of diagnosing and correcting the problem before putting the code into
>> production. If the error is ignored, the program will very likely
>> continue to corrupt your data in subtle ways; tracking it down and
>> fixing it is going to be difficult if the error occurs at a customer
>> site, or even during an important demo.

>
>I believe you are completely wrong on this point. Very often a SIGSEGV
>will be caused by (say) a single bad array access - the consequences
>will be highly localized, and carrying on with the program will not
>cause any significant problems.


How on earth would you know what the consequences might be? If the
program in question is calculating my paycheck, I don't want any bad
array access to be ignored.

What kind of programs do you write? Games?
>
>Who wants their customer to run their program and have it just crash
>with a segfault? That hardly comes across as professional.


What's not professional is writing code that causes segfaults.

> Better to try
>your best to carry on and weather the storm than to just dump the user
>with a crash.
>
>I can understand that for debugging purposes you might want to have
>SIGSEGV etc. generate a core file, but in production code the default
>should be for these signals to be ignored.


In production code, those signals should never be generated. If they
are, they should crash, so that the user can complain, and someone can
fix it.

--
Al Balmer
Sun City, AZ
 
Reply With Quote
 
Shadowman
Guest
Posts: n/a
 
      11-02-2007
Leet Jon wrote:
> On 2 Nov 2007 at 19:10, Keith Thompson wrote:
>> However, letting a program continue running by default after a
>> catastrophic data-corrupting failure would not be a good idea. If a
>> program dies immediately after "an invalid access to storage" (which
>> is all the C standard says about SIGSEGV), then you have a good chance
>> of diagnosing and correcting the problem before putting the code into
>> production. If the error is ignored, the program will very likely
>> continue to corrupt your data in subtle ways; tracking it down and
>> fixing it is going to be difficult if the error occurs at a customer
>> site, or even during an important demo.

>
> I believe you are completely wrong on this point. Very often a SIGSEGV
> will be caused by (say) a single bad array access - the consequences
> will be highly localized, and carrying on with the program will not
> cause any significant problems.
>
> Who wants their customer to run their program and have it just crash
> with a segfault? That hardly comes across as professional. Better to try
> your best to carry on and weather the storm than to just dump the user
> with a crash.
>
> I can understand that for debugging purposes you might want to have
> SIGSEGV etc. generate a core file, but in production code the default
> should be for these signals to be ignored.
>


OK, but you really haven't made a case that it would be worthwhile to
change the default behavior. What's wrong with supplying your own
signal handler when you want something else?

--
SM
rot13 for email
 
Reply With Quote
 
Martin Vuille
Guest
Posts: n/a
 
      11-02-2007
Leet Jon <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> Hi what's the reason for having the default disposition for
> SIGSEGV, SIGFPE, SIGBUS etc to be terminating the program,
> when these signals can just be ignored by the program?


In spite of what you seem to believe, an application is not
allowed to ignore the signal, and is very limited in how it can
handle the signal. To quote POSIX/SUSv3:

"The behavior of a process is undefined after it ignores a SIGFPE,
SIGILL, SIGSEGV, or SIGBUS signal that was not generated by kill
( ),sigqueue( ),or raise( )."

and

"The behavior of a process is undefined after it returns normally
from a signal-catching function for a SIGBUS, SIGFPE, SIGILL, or
SIGSEGV signal that was not generated by kill( ),sigqueue( ),or
raise( )."

MV

--
I do not want replies; please follow-up to the group.
 
Reply With Quote
 
jameskuyper@verizon.net
Guest
Posts: n/a
 
      11-02-2007
Leet Jon wrote:
> On 2 Nov 2007 at 19:10, Keith Thompson wrote:
> > However, letting a program continue running by default after a
> > catastrophic data-corrupting failure would not be a good idea. If a
> > program dies immediately after "an invalid access to storage" (which
> > is all the C standard says about SIGSEGV), then you have a good chance
> > of diagnosing and correcting the problem before putting the code into
> > production. If the error is ignored, the program will very likely
> > continue to corrupt your data in subtle ways; tracking it down and
> > fixing it is going to be difficult if the error occurs at a customer
> > site, or even during an important demo.

>
> I believe you are completely wrong on this point. Very often a SIGSEGV
> will be caused by (say) a single bad array access - the consequences
> will be highly localized, and carrying on with the program will not
> cause any significant problems.


In general, if that bad array access is a write, it may completely
mess up some other part of the program. Also, code sufficiently
defective to generate a bad array access is extremely unlikely to
generate only one such access; they usually produce large numbers of
them.

> Who wants their customer to run their program and have it just crash
> with a segfault?


Given the choice between crashing, and continuing to run, I strongly
prefer the crash. If someone desperately needs that program to be
running, they presumably need it to run correctly, and that's highly
unlikely after an ignored SIGSEG signal.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-03-2007
Leet Jon <(E-Mail Removed)> writes:
> On 2 Nov 2007 at 19:10, Keith Thompson wrote:
>> However, letting a program continue running by default after a
>> catastrophic data-corrupting failure would not be a good idea. If a
>> program dies immediately after "an invalid access to storage" (which
>> is all the C standard says about SIGSEGV), then you have a good chance
>> of diagnosing and correcting the problem before putting the code into
>> production. If the error is ignored, the program will very likely
>> continue to corrupt your data in subtle ways; tracking it down and
>> fixing it is going to be difficult if the error occurs at a customer
>> site, or even during an important demo.

>
> I believe you are completely wrong on this point. Very often a SIGSEGV
> will be caused by (say) a single bad array access - the consequences
> will be highly localized, and carrying on with the program will not
> cause any significant problems.
>
> Who wants their customer to run their program and have it just crash
> with a segfault? That hardly comes across as professional. Better to try
> your best to carry on and weather the storm than to just dump the user
> with a crash.


Better to continue with bad data? Better to corrupt the user's
important files than to crash and leave them in their initial state?
Better to continue operating incorrectly and produce wrong answers, as
long as it *looks* good?

I don't think so.

Your goal should be for your code never to produce a SIGSEGV in the
first place. Since all software has bugs, that's not always
achievable, but you should certainly want to *know* when the program
produces SIGSEGV (or any other signal that indicates a problem).

> I can understand that for debugging purposes you might want to have
> SIGSEGV etc. generate a core file, but in production code the default
> should be for these signals to be ignored.


At the very least, you might consider handling the signal and logging
the error (and, preferably, cleanly shutting down the program). If
you just ignore it, then you might never know that there's a problem
-- except that users will decide that your software is unreliable.

What you advocate is the equivalent of putting a piece of black tape
over the oil warning light on your car's dashboard. It makes for a
more pleasant driving experience -- until your engine seizes up and
leaves you stranded in the middle of nowhere.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"Target of signal assignment is not a signal" Nicolas Moreau VHDL 9 07-25-2007 04:21 PM
Re: How to make an internal signal embedded deep in hierarchy to a gloal output signal Weng Tianxiang VHDL 2 01-30-2007 12:58 PM
Aside from delta cycles and/or resolution functions, how can the effective value of a signal differ from a driving signal of its? Colin Paul Gloster VHDL 0 01-11-2007 01:31 PM
threading.Thread vs. signal.signal Jack Orenstein Python 0 09-17-2005 11:24 PM
Async-signal safe functions in signal handlers (unix) Michael Pronath Python 1 01-03-2005 01:10 PM



Advertisments