Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #10678 > unrolled thread

C error messages

Back to article view | Back to comp.lang.c

Contents

  C error messages Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-09-21 20:25 +0000
    Re: C error messages blp@cs.stanford.edu (Ben Pfaff) - 2011-09-21 13:36 -0700
      Re: C error messages Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-09-22 21:07 +0000
        Re: C error messages blp@cs.stanford.edu (Ben Pfaff) - 2011-09-22 14:34 -0700
        Re: C error messages Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-09-22 16:05 -0600
        Re: C error messages Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-22 21:21 -0400
    Re: C error messages Nobody <nobody@nowhere.com> - 2011-09-22 18:08 +0100
    Re: C error messages Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-23 12:00 +0300

#10678 — C error messages

Hello:

What is the principle difference between a Bus Error and a Segmentation 
Fault please.

Thanks
QP

[toc] | [next] | [standalone]

#10679

Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:

> What is the principle difference between a Bus Error and a Segmentation 
> Fault please.

It's implementation-specific.  Not all implementations have
either one.

The glibc manual describes one common distinction:

 -- Macro: int SIGSEGV
     This signal is generated when a program tries to read or write
     outside the memory that is allocated for it, or to write memory
     that can only be read.  (Actually, the signals only occur when the
     program goes far enough outside to be detected by the system's
     memory protection mechanism.)  The name is an abbreviation for
     "segmentation violation".

     Common ways of getting a `SIGSEGV' condition include dereferencing
     a null or uninitialized pointer, or when you use a pointer to step
     through an array, but fail to check for the end of the array.  It
     varies among systems whether dereferencing a null pointer generates
     `SIGSEGV' or `SIGBUS'.

 -- Macro: int SIGBUS
     This signal is generated when an invalid pointer is dereferenced.
     Like `SIGSEGV', this signal is typically the result of
     dereferencing an uninitialized pointer.  The difference between
     the two is that `SIGSEGV' indicates an invalid access to valid
     memory, while `SIGBUS' indicates an access to an invalid address.
     In particular, `SIGBUS' signals often result from dereferencing a
     misaligned pointer, such as referring to a four-word integer at an
     address not divisible by four.  (Each kind of computer has its own
     requirements for address alignment.)

     The name of this signal is an abbreviation for "bus error".

-- 
"...what folly I commit, I dedicate to you."
--William Shakespeare, _Troilus and Cressida_

[toc] | [prev] | [next] | [standalone]

#10726

Thanks Ben.

Would you say then that a Bus Error is a showstopper but a Segmentation 
Fault is less serious, so it would be worth catching that signal, maybe 
writing a message to a log file, but then continuing with the program?


On Wed, 21 Sep 2011 13:36:06 -0700, Ben Pfaff wrote:
> Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:
> 
>> What is the principle difference between a Bus Error and a Segmentation
>> Fault please.
> 
> It's implementation-specific.  Not all implementations have either one.
> 
> The glibc manual describes one common distinction:
> 
>  -- Macro: int SIGSEGV
>      This signal is generated when a program tries to read or write
>      outside the memory that is allocated for it, or to write memory
>      that can only be read.  (Actually, the signals only occur when the
>      program goes far enough outside to be detected by the system's
>      memory protection mechanism.)  The name is an abbreviation for
>      "segmentation violation".
> 
>      Common ways of getting a `SIGSEGV' condition include dereferencing
>      a null or uninitialized pointer, or when you use a pointer to step
>      through an array, but fail to check for the end of the array.  It
>      varies among systems whether dereferencing a null pointer generates
>      `SIGSEGV' or `SIGBUS'.
> 
>  -- Macro: int SIGBUS
>      This signal is generated when an invalid pointer is dereferenced.
>      Like `SIGSEGV', this signal is typically the result of
>      dereferencing an uninitialized pointer.  The difference between the
>      two is that `SIGSEGV' indicates an invalid access to valid memory,
>      while `SIGBUS' indicates an access to an invalid address. In
>      particular, `SIGBUS' signals often result from dereferencing a
>      misaligned pointer, such as referring to a four-word integer at an
>      address not divisible by four.  (Each kind of computer has its own
>      requirements for address alignment.)
> 
>      The name of this signal is an abbreviation for "bus error".

[toc] | [prev] | [next] | [standalone]

#10727

Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:

> Would you say then that a Bus Error is a showstopper but a Segmentation 
> Fault is less serious, so it would be worth catching that signal, maybe 
> writing a message to a log file, but then continuing with the program?

I wouldn't do that in either case.
-- 
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield

[toc] | [prev] | [next] | [standalone]

#10728

Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:
>
>
> On Wed, 21 Sep 2011 13:36:06 -0700, Ben Pfaff wrote:
>> Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:
>> 
>>> What is the principle difference between a Bus Error and a Segmentation
>>> Fault please.
>> 
>> It's implementation-specific.  Not all implementations have either one.
>> 
>> The glibc manual describes one common distinction:
>> 
>>  -- Macro: int SIGSEGV
>>      This signal is generated when a program tries to read or write
>>      outside the memory that is allocated for it, or to write memory
>>      that can only be read.  (Actually, the signals only occur when the
>>      program goes far enough outside to be detected by the system's
>>      memory protection mechanism.)  The name is an abbreviation for
>>      "segmentation violation".
>> 
>>      Common ways of getting a `SIGSEGV' condition include dereferencing
>>      a null or uninitialized pointer, or when you use a pointer to step
>>      through an array, but fail to check for the end of the array.  It
>>      varies among systems whether dereferencing a null pointer generates
>>      `SIGSEGV' or `SIGBUS'.
>> 
>>  -- Macro: int SIGBUS
>>      This signal is generated when an invalid pointer is dereferenced.
>>      Like `SIGSEGV', this signal is typically the result of
>>      dereferencing an uninitialized pointer.  The difference between the
>>      two is that `SIGSEGV' indicates an invalid access to valid memory,
>>      while `SIGBUS' indicates an access to an invalid address. In
>>      particular, `SIGBUS' signals often result from dereferencing a
>>      misaligned pointer, such as referring to a four-word integer at an
>>      address not divisible by four.  (Each kind of computer has its own
>>      requirements for address alignment.)
>> 
>>      The name of this signal is an abbreviation for "bus error".

> Thanks Ben.
>
> Would you say then that a Bus Error is a showstopper but a Segmentation 
> Fault is less serious, so it would be worth catching that signal, maybe 
> writing a message to a log file, but then continuing with the program?

No.  They're both showstoppers.

If anything, the segmentation violation is worse than the bus error --
really, the only thing that can cause it is a hosed data structure or
something even worse (like an OS bug).  If you get one, you're dead.

A bus error can conceivably be a result of code with alignment errors
that could be reconstructed.  I'm thinking of the yacc that shipped with
the first Sun Sparc machines, which generated code with exactly that
flaw, and which could conceivably have been patched-up (though fixing
yacc was obivously a more-right thing to do, and what happened in a
short time).  Also, the original IBM POWER architecture specified that
unaligned accesses that crossed cache boundaries would trap, and were
supposed to be patched in a handler.

There are a very few applications people can point to that are
exceptions (seg fault handlers in debuggers are probably the poster
child).  But if you are coding something that is one of those
exceptions, you know it and don't need to ask the question.

[toc] | [prev] | [next] | [standalone]

#10731

On 9/22/2011 5:07 PM, Quentin Pope wrote:
> Thanks Ben.
>
> Would you say then that a Bus Error is a showstopper but a Segmentation
> Fault is less serious, so it would be worth catching that signal, maybe
> writing a message to a log file, but then continuing with the program?

     No.  Both are evidence that your program has followed a bad
pointer (or bad array index), meaning that your code can no longer
trust its data.  If you "recover" from either fault, what reason
have you to believe that any subsequent `if' will go in the right
direction?  What degree of trust can you place in the program's
actions or output?  The C Standard says that continuing from this
sort of signal yields undefined behavior; I believe (could be wrong
here) that POSIX says much the same thing.  There is very little,
very very little, that can be done reliably after such an event.

     Poor analogy, but maybe it gets the right flavor: After entrusting
your retirement savings to a financial advisor, you happen to catch
said advisor embezzling from your accounts.  Do you write a message to
a log file and keep on going, or do you do something more drastic?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#10714

On Wed, 21 Sep 2011 20:25:55 +0000, Quentin Pope wrote:

> What is the principle difference between a Bus Error and a Segmentation 
> Fault please.

Ultimately, it depends upon which interrupt the hardware generates.

Typically, SIGSEGV arises from accessing a virtual memory page which
is either not backed by physical memory or which doesn't permit the
requested operation (e.g. write to a read-only page), while SIGBUS arises
from a misaligned access on an architecture which has alignment
constraints.

[toc] | [prev] | [next] | [standalone]

#10742

Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:
> Hello:
> 
> What is the principle difference between a Bus Error and a Segmentation 
> Fault please.

Given that it's possible for programs not written in C to generate the
same messages, and that there are implementations that support C and
which do not generate such messages, it should be fairly obvious that
your question has nothing to do with C.

However, I suspect you won't get full marks on your assignment if you
write that, so you still need to ask a platform-specific newsgroup to
do your homework for you.

Phil
-- 
"Religion is what keeps the poor from murdering the rich."
-- Napoleon

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web