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~
29  2110 
"Leet Jon" <jo*@nospam.com schrieb im Newsbeitrag
news:sl******** ***********@nos pam.com...
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
Leet Jon <jo*@nospam.com 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.progr ammer than
here in comp.lang.c. (I just noticed the cross-post; I've set
followups to comp.unix.progr ammer.)
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_Keit h) ks***@mib.org <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"
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.
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.
On Fri, 2 Nov 2007 21:16:31 +0100 (CET), Leet Jon <jo*@nospam.com >
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
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
Leet Jon <jo*@nospam.com wrote in
news:sl******** ***********@nos pam.com:
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.
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.
Leet Jon <jo*@nospam.com 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_Keit h) ks***@mib.org <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" This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Klaus Neuner |
last post by:
Hello,
consider the following two programs:
# (1)
import sys, signal
def alarm_handler(signum, frame):
raise
|
by: Martin McCormick |
last post by:
A C program contains several signal statements to remove a
lock file if the program gets killed:
/*Set up interrupt handler to catch ctrl-C so that lock file can be removed.*/
signal(SIGINT,crash);
signal(SIGBUS,crash);
signal(SIGSEGV,crash);
This part works. Those signals cause the "crash.c" module to
run and get rid of the lock. Is there a standard way to also print
|
by: LeTubs |
last post by:
Hi
I'm not sure if this is correct ...place to post but here goes
This is what i'm trying to do, I want to write a signal / alarm handler
( I don't know which hence the posting here, as once I know the proper
name /useage then I'll use google to try and find out more
information )....
Thus any tips or pointers would be helpful (and I'm using a UNIX variant as
OS)
|
by: Jackie |
last post by:
Hi everyone,
I'd like to know when and how signals are used (e.g. SIGFPE, SIGABRT,
SIGTERM, SIGSEGV, SIGINT)? Thank you so much.
|
by: None |
last post by:
Hello,
1.
The prototype of function signal in signal.h:
void (*signal(int sig, void (*func)(int)))(int);
is some complex to me. Would you please explain it to me in detail with
the C language syntax itself. Thank you!
| | |
by: Stanley S |
last post by:
Hi,
Are Signal Handling part of ANSI C?
I am not able to find any reference of Sig Handling in Stephen Prata's
"C Primer Plus".
The usage of signals is to trap errors I guess. (It looks similiar to
the concept of try-catch to me.) It seems to relate more to nix OS. Are
signals handling part of Windows too?
|
by: Udai Kiran |
last post by:
Hi all
Iam having trouble with signal handler. Where will the execution
return after invoking a signal handler when that particular signal is
recieved? will return to the point where we register the signal?
The following code is recieveing recursive signals.
2 #include <stdio.h>
3 #include <stdlib.h>
4 #include <unistd.h>
5
|
by: david |
last post by:
I'm developing a program that runs using an asyncore loop. Right now
I can adequately terminate it using Control-C, but as things get
refined I need a better way to stop it. I've developed another
program that executes it as a child process using popen2.Popen4(). I
was attempting to use signals to stop it (using os.kill()) but I keep
running into a problem where sending the signal causes an infinite
loop of printing the message...
|
by: thagor2008 |
last post by:
Is the behaviour of throwing exceptions in a unix signal handler
defined?
eg:
void sighandler(int sig)
{
... do something
throw myobj;
}
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
