This may belong in the C Programming forum, but here goes anyway...

What would cause a bus error? I searched google for a cause, but came up with some conflicting reports...
Could it be caused by [lack of] disk space?
A lot of the pages I found mentioned linking with the incorrect versions of the library. But in that case, would it compile correctly?

Basically, I am curious as to why we had a job dump core on a bus error. It ran nearly to normal completion time, then simply poo-pood.

In the case that it may make a difference, it's a job that interfaces with an Oracle database on HP-UX 11. The things that had changed were that the process was recompiled, AND we were at 96% (df -k) on that disk...

Not too important for me to know right now, but I am curious, and who wants to wait for developers to tell me what happened?

The bus in question is the address buss and it contains an illegal value. This is almost always the result of dereferencing a pointer that contains an illegal value.

Here is a program that, I think, will compile with every C or C++ compiler, but should cause a bus error when the second printf is attempted...

I only know that if one trys to access a memory which in a readonly segment, the system will bumpup a Bus Error signal.

Do you have the source for the program? You could always examine the core to find out what is happening.

By "access" I guess you mean trying to store something there. Not to belabor the obvious, but it is legal to read a read-only segment.

There are two signals that can be delivered to a process that attempts something with an illegal memory address:

SIGBUS (ksh will say Bus error(coredump))
SIGSEGV (ksh will say Memory fault(coredump))

I've been looking through my library and I can't find any documentation that states which signal must be delivered under a specific condition. It may be that some versions of unix only use one or the other for everything. The kernel really depends on the cpu to catch these and it may be that some cpu's simply have a single trap to handle all bad addresses.

Still to me these errors have slightly different meanings, although I must admit that this is based mostly on C programming in an HP-UX environment.

SIGBUS means that you have asked to cpu to do something that is impossible. More to the point, the cpu can catch this error immediately by looking at the virtual address. There is no need to even attempt to convert the virtual address to a physical address. This is why cpu's bother to have a two-tiered check on an address. Converting a virtual address to a physical address can be a somewhat expensive operation.

SIGSEGV means that you have asked the cpu to do something that is illegal. If the kernel wanted to, it could fiddle with things to render the attempted operation legal. This error is caught after the attempted conversion of the virtual address to a physical address.

I would tend to expect that the situation tonyt is describing would result in a SIGSEGV rather than a SIGBUS....except that if you have a pointer that is both misaligned and in the wrong segment, you won't get both signals, you only get a SIGBUS. If an int is 4 bytes on your system and you try to store an int at random addresses in a read-only segment, then yes 75% of the time you will get a SIGBUS, while 25% of the time your pointer is aligned and you get the SIGSEGV.

Still tonyt may have a system that works differently than mine. And if a system can only deliver a single signal for address problems, SIGBUS would be my choice.