C error messages

Discussion in 'C Programming' started by Quentin Pope, Sep 21, 2011.

  1. Quentin Pope

    Quentin Pope Guest

    Hello:

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

    Thanks
    QP
     
    Quentin Pope, Sep 21, 2011
    #1
    1. Advertising

  2. Quentin Pope

    Ben Pfaff Guest

    Quentin Pope <> 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_
     
    Ben Pfaff, Sep 21, 2011
    #2
    1. Advertising

  3. Quentin Pope

    Nobody Guest

    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.
     
    Nobody, Sep 22, 2011
    #3
  4. Quentin Pope

    Quentin Pope Guest

    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 <> 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".
     
    Quentin Pope, Sep 22, 2011
    #4
  5. Quentin Pope

    Ben Pfaff Guest

    Quentin Pope <> 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
     
    Ben Pfaff, Sep 22, 2011
    #5
  6. Quentin Pope

    Joe Pfeiffer Guest

    Quentin Pope <> writes:
    >
    >
    > On Wed, 21 Sep 2011 13:36:06 -0700, Ben Pfaff wrote:
    >> Quentin Pope <> 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.
     
    Joe Pfeiffer, Sep 22, 2011
    #6
  7. Quentin Pope

    Eric Sosman Guest

    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
    d
     
    Eric Sosman, Sep 23, 2011
    #7
  8. Quentin Pope

    Phil Carmody Guest

    Quentin Pope <> 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
     
    Phil Carmody, Sep 23, 2011
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. gary artim

    recordset error/perl messages

    gary artim, Feb 6, 2004, in forum: Perl
    Replies:
    0
    Views:
    494
    gary artim
    Feb 6, 2004
  2. Thomas Connolly

    Validation Summary not showing error messages

    Thomas Connolly, Jul 9, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    675
    Thomas Connolly
    Jul 9, 2003
  3. Teemu Keiski
    Replies:
    0
    Views:
    507
    Teemu Keiski
    Jul 9, 2003
  4. Gary

    Error messages

    Gary, Aug 13, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    539
    Kevin Spencer
    Aug 13, 2003
  5. Cowboy \(Gregory A. Beamer\)

    Re: Custom Error Messages...

    Cowboy \(Gregory A. Beamer\), Nov 24, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    517
    Cowboy \(Gregory A. Beamer\)
    Nov 25, 2003
Loading...

Share This Page