> To prevent this from happening, the X server will install a signal
> handler for SIGBUS, check if a shared memory object is being accessed
> and patch things up (by mmap'ing anonymous memory on top of the
> mapping). This code can be extended of course by handling SIGSEGV as
> well. But this me
> Date: Tue, 24 Jun 2014 15:53:20 -0700
> From: Matthew Dempsky
>
> On Tue, Jun 24, 2014 at 11:04:10AM -0700, Matthew Dempsky wrote:
> > SIGBUS/BUS_ADRERR: Accessing a mapped page that exceeds the end of
> > the underlying mapped file.
>
> Generating SIGBUS for this case has proven controver
Matthew -- fine, you collected information. Thank you.
It is quite clear that POSIX set in stone an accident, a significant
error in my opinion. Anyone with enough expertise can recognize this
is an accident in the SVR4 codebase, which ended up being "ratified"
(in quotes, because the more mista
On Tue, Jun 24, 2014 at 11:04:10AM -0700, Matthew Dempsky wrote:
> SIGBUS/BUS_ADRERR: Accessing a mapped page that exceeds the end of
> the underlying mapped file.
Generating SIGBUS for this case has proven controversial due to
concern that this is Linux invented behavior and not compatible wi
POSIX specifies these error cases for memory faults:
SIGSEGV/SEGV_MAPERR: Accessing an unmapped page.
SIGSEGV/SEGV_ACCERR: Reading from a non-readable or writing to a
non-writable page.
SIGBUS/BUS_ADRERR: Accessing a mapped page that exceeds the end of
the underlying mapped file.
I a
