C error messages

[Quentin Pope]

Hello:

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

Thanks
QP

 

[Ben Pfaff]

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".

 

[Nobody]

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.

 

[Quentin Pope]

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?

 

[Ben Pfaff]

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.

 

[Joe Pfeiffer]

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.

 

[Eric Sosman]

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?

 

[Phil Carmody]

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