Serious compatibility breakage in -current.
bakul at bitblocks.com
Fri Nov 30 08:24:10 PST 2007
> > The switch from SIGBUS to SIGSEGV is well motivated.
> Is it? I see no mention of it in the commit log for the revision that
> actually implemented the change. David argued on -CURRENT that it is
> more POSIXly correct, provided that he interpreted POSIX correctly; how
> do other operating systems behave in this case?
There are two issues: the right thing to do for POSIX and
compatibility with older versions.
See the memory protection section in
* Write attempts to memory that was mapped without write access, or any
access to memory mapped PROT_NONE, shall result in a SIGSEGV signal.
* References to unmapped addresses shall result in a SIGSEGV signal.
* Reference to whole pages within the mapping, but beyond the current
length of the object, shall result in a SIGBUS signal.
FreeBSD's behavior until 7.0 was opposite of this! It has
followed what has been done at least since 4.3BSD (1986?)
which gave SIGBUS on a protection violation and SIGSEG for
access outside any mapped area.
Solaris mmap man page is not clear on this -- it says you can
get SIGSEGV or SIGBUS but doesn't indicate which under what
The change made for 7.0 doesn't quite do the right thing
either as it doesn't distinguish between unmapped area and
wrong kind of access -- you get SIGSEGV for both.
So you are breaking compatibility for no good reason.
Kris Kennaway argus
> it is far too late in the release cycle to identify and revert the ports
> that already caught up to expecting SIGSEGV, so we'd be breaking a
> different set of applications instead).
This is a mess but IMHO the two kinds of breakages are not
equal. For better standards compliance another kernel change
will have to be made in the future in any case.
More information about the freebsd-current