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~
Nov 2 '07
29  2111 
Leet Jon wrote:
On 2 Nov 2007 at 20:34, Al Balmer wrote:
>>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.
Perhaps you are unaware that some C code is run in safety-critical
environments - having a program that dumps core at the drop of a hat
rather than carrying on running could literally be the difference
between life and death. OK, so *maybe* the error condition causing the
SIGSEGV will propagate and bring the program down later, but taking that
chance is a better option than immediately failing.
~Jon~
Continue after error http://www.netcomp.monash.edu.au/cpe...~tgallagh.html
yeah right.
Leet Jon wrote:
>
.... snip ...
>
Perhaps you are unaware that some C code is run in safety-critical
environments - having a program that dumps core at the drop of a
hat rather than carrying on running could literally be the
difference between life and death. OK, so *maybe* the error
condition causing the SIGSEGV will propagate and bring the program
down later, but taking that chance is a better option than
immediately failing.
Apparently you are unaware that such a program has absolutely no
business running in such a 'safety critical environment'.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home .att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
On Sat, 03 Nov 2007 04:14:45 GMT, al****@brothers .orgy (Almond) wrote:
>Send any feedback, ideas, suggestions, test results to
Here's some feedback: Your advertising, release notes, and privacy
policy are inappropriate here, even in a sig block.
Limit your signature to three or four lines, which is plenty of space
to include your URL.
--
Al Balmer
Sun City, AZ
On Sat, 3 Nov 2007 10:15:52 +0100 (CET), Leet Jon <jo*@nospam.com >
wrote:
>On 2 Nov 2007 at 20:34, Al Balmer wrote:
>>>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.
Perhaps you are unaware that some C code is run in safety-critical
environments
That's pretty funny, considering I wrote safety-critical code for the
process control industry for over twenty years. Food, petroleum,
polymers, paper, you name it.
If the coolant control program on a PVC reactor crashes, you don't
ignore it and keep cooking. You kill not only the program, but the
process. Otherwise, you kill people.
>- having a program that dumps core at the drop of a hat
rather than carrying on running could literally be the difference
between life and death. OK, so *maybe* the error condition causing the
SIGSEGV will propagate and bring the program down later, but taking that
chance is a better option than immediately failing.
Don't bother applying for a job here. We don't insist that all
new-hires be expert, but we do want them to be trainable.
--
Al Balmer
Sun City, AZ
["Followup-To:" header set to comp.unix.progr ammer.]
On 2007-11-03, Leet Jon <jo*@nospam.com wrote:
On 2 Nov 2007 at 20:34, Al Balmer wrote:
>>>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.
Perhaps you are unaware that some C code is run in safety-critical
environments - having a program that dumps core at the drop of a hat
rather than carrying on running could literally be the difference
between life and death. OK, so *maybe* the error condition causing the
Allowing a process with corrupted data to continue running can also
cause death.
SIGSEGV will propagate and bring the program down later, but taking that
chance is a better option than immediately failing.
~Jon~
--
On 3 Nov, 09:15, Leet Jon <j...@nospam.co mwrote:
On 2 Nov 2007 at 20:34, Al Balmer wrote:
>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.
Perhaps you are unaware that some C code is run in safety-critical
environments
OHMYGOD
*please* tell me you don't write safety critical code!
- having a program that dumps core at the drop of a hat
rather than carrying on running could literally be the difference
between life and death. OK, so *maybe* the error condition causing the
SIGSEGV will propagate and bring the program down later, but taking that
chance is a better option than immediately failing.
--
Nick Keighley
Nick Keighley wrote:
On 3 Nov, 09:15, Leet Jon <j...@nospam.co mwrote:
>On 2 Nov 2007 at 20:34, Al Balmer wrote:
>>>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.
Perhaps you are unaware that some C code is run in safety-critical
environments
OHMYGOD
*please* tell me you don't write safety critical code!
>- having a program that dumps core at the drop of a hat
rather than carrying on running could literally be the difference
between life and death. OK, so *maybe* the error condition causing the
SIGSEGV will propagate and bring the program down later, but taking that
chance is a better option than immediately failing.
--
Nick Keighley
I suspect he did, until his boss found out what he was planning and canned his
ass. Now he's looking to prove his boss wrong. That of he's a troll.
"Al Balmer" <al******@att.n eta écrit dans le message de news: r6************* *************** ****@4ax.com...
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
catastrophi c 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.
Someone else might want to check first if the error is worth such a drastic
treatment.
With your suggested behaviour, the paycheck is not printed, and who knows
when the problem will be fixed... If you can wait for your paycheck, you'll
be OK, else too bad.
Alternately, let it print the damn check, there is a good chance the check
will be correct and arrice in time. There is some possibility that the
error is so small as to not be worth reporting. If the error is large, the
you can complain and have it fixed... Or you will not complain and wait for
the bank to figure where these millions came from ;-)
If you are the payer, you probably want the process to stop. If you are the
payee, it is not so obvious.
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.
If they are, they should be logged and reported yet best efforts should be
extended to minimize the impact on the user. Warning the user of potential
malfunction, requesting urgent attention may be more appropriate than a core
dump with no warning and no restart. Use common sense to determine what be
least impact the user. When the oil gauge trips, the dashboard turns a
light on, it does not immediately block the engine, fire the ejector seats
and vaporize the contents of the trunk.
--
Chqrlie.
Charlie Gordon wrote:
"Al Balmer" <al******@att.n eta écrit dans le message de news:
r6************* *************** ****@4ax.com...
>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:
....
>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.
Someone else might want to check first if the error is worth such a drastic
treatment.
With your suggested behaviour, the paycheck is not printed, and who knows
when the problem will be fixed... If you can wait for your paycheck, you'll
be OK, else too bad.
You're much better off with the program aborting than with it producing
large amounts of problems, which is the most likely case. It might
transfer money from one account to another, without making the balancing
adjustment to another account. It might accidentally wipe out all of the
employee records. It might accidentally wipe out a small random subset
of the employee records, which is worse because it will take longer to
notice.
Alternately, let it print the damn check, there is a good chance the check
will be correct and arrice in time. There is some possibility that the
error is so small as to not be worth reporting. If the error is large, the
you can complain and have it fixed... Or you will not complain and wait for
the bank to figure where these millions came from ;-)
Everything about that paragraph is wrong. The chances are not good that
the paycheck will be correct and arrive on time. There's a large
probability that the error will be a big one. There is no error so small
that it's not worth reporting; tax auditors tend to get very concerned
about even small errors, because they think they might be a signs of
something more serious (and they are right to think that). If the error
is large, fixing it can be very expensive for the payer, and a lot of
hassle for the payee.
....
>>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.
If they are, they should be logged and reported yet best efforts should be
extended to minimize the impact on the user. Warning the user of potential
malfunction, requesting urgent attention may be more appropriate than a core
dump with no warning and no restart.
The core dump IS your warning, and restart should NOT be attempted until
the problem has been resolved, otherwise you could easily add to the
damage created by the first run of the program.
Use common sense to determine what be
least impact the user. When the oil gauge trips, the dashboard turns a
light on, it does not immediately block the engine, fire the ejector seats
and vaporize the contents of the trunk.
Yes, but the oil guage isn't analogous to a SIGSEGV. A better analogy
would be to compare a SIGSEGV to the motion sensor alarm which triggers
an air bag to explode in your face. When that air bag explodes, you are
guaranteed to lose control of the car, if you haven't already done so
(as I can unfortunately testify to from personal experience). However,
if that motion sensor trips, the situation is generally so serious that
you're probably better off losing control with an airbag in your face,
then you would be if you retained control with no airbag protection.
This isn't necessarily true; in some cases the airbag can kill you when
you would have survived without it, but in general you're safer with it
exploding in your face. That is a very accurate analogy to a SIGSEGV.
On Wed, 7 Nov 2007 15:38:28 +0100, "Charlie Gordon" <ne**@chqrlie.o rg>
wrote:
>"Al Balmer" <al******@att.n eta écrit dans le message de news:
r6************ *************** *****@4ax.com.. .
>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
catastroph ic 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.
Someone else might want to check first if the error is worth such a drastic
treatment.
With your suggested behaviour, the paycheck is not printed, and who knows
when the problem will be fixed... If you can wait for your paycheck, you'll
be OK, else too bad.
And if the error is in a control process that blows up a reactor and
kills a few people? How do you correct that mistake?
I think your point is that the problem analysis should take account of
the consequences of an error - that's obvious. Basic systems
engineering. I'm not advocating that the only possible way to treat a
segfault is to stop the program, though in a properly designed control
system, it's usually the best way.
>
Alternately, let it print the damn check, there is a good chance the check
will be correct and arrice in time. There is some possibility that the
error is so small as to not be worth reporting. If the error is large, the
you can complain and have it fixed... Or you will not complain and wait for
the bank to figure where these millions came from ;-)
All of which will cause more problems, eventually, both to the payer
and the payee. If the system stops, it *will* get fixed. People in
data processing take payroll runs *very* seriously. Did you imagine
that they would just not pay anybody else, and hope for a better run
next week?
>
If you are the payer, you probably want the process to stop. If you are the
payee, it is not so obvious.
>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.
If they are, they should be logged and reported yet best efforts should be
extended to minimize the impact on the user. Warning the user of potential
malfunction, requesting urgent attention may be more appropriate than a core
dump with no warning and no restart.
How do you warn of a segfault before it happens?
Use common sense to determine what be
least impact the user. When the oil gauge trips, the dashboard turns a
light on, it does not immediately block the engine, fire the ejector seats
and vaporize the contents of the trunk.
Not "common sense." Systems analysis.
--
Al Balmer
Sun City, AZ 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: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
| | |
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: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
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: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
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
| |
