Re: Serious compatibility breakage in -current.

On Thu, Nov 29, 2007 at 02:26:11AM -0800, Carl Shapiro wrote:
Developers,

FreeBSD 7 has changed the protection violation signal from SIGBUS to
SIGSEGV. Unfortunately, when an old binary is run on a current
FreeBSD system, protection violations cause a SIGSEGV to be delivered
to the executable instead of the anticipated SIGBUS. Binaries
compiled on older versions of FreeBSD are not prepared to handle
SIGSEGV in response to page protection violations.

One consequence of this change is that applications that handle page
protection violations, such as the CMUCL Lisp compiler have broken.
CMUCL binaries compiled for FreeBSD 4, FreeBSD 5, and FreeBSD 6 crash
on -current. Investments FreeBSD users have in binaries that handle
page protection violations, such as things that link against boehm-gc,
are lost forever. This significantly increases the cost of an upgrade
to FreeBSD 7.

The switch from SIGBUS to SIGSEGV is well motivated. However, it is
not clear that consideration was given to binaries running under
compat{4,5,6}x. One would expect the compat infrastructure to
translate protection violation signals from SIGSEGV to SIGBUS while
executing older binaries. This would ensure that the applications
that establish SIGBUS handlers to catch protection violations continue
to work.

Among the open source operating systems the FreeBSD project has one of
the best traditions of supporting old binaries. It would truly be a
shame for this tradition to abruptly end as of the next major release.
As a developer who supports several versions of FreeBSD through
binary compatibility anything that can help us avoid breakage as of
the next FreeBSD release would be appreciated.

Thanks,

Carl (and the many FreeBSD users of CMUCL)

I can confirm that FreeBSD-6 binary of the CMUCL 19d does not work. It
is interesting that sbcl has no problems on RELENG_7.

May be sbcl was trapping both SIGBUS and SIGSEGV? Anyway we
find this in their commit log:

Sep 26 2007 11:42 sa2c 1.0.10.4: Use variable for SIG_MEMORY_FAULT on
FreeBSD When SIGBUS is signalled on FreeBSD 7,
or SIGSEGV is signalled on FreeBSD 6 or earlier,
it's very hard to debug if both of the signals
are hooked for GC.

Instead to hook both signals, define
SIG_MEMORY_FAULT as variable and set it at
startup. [Details]

So they worked around (but it still won't help any old
binaries). There were some messages about this change on PLT
Scheme mailing list as well. Unfortunately they don't
complain here!

See for example:
http://list.cs.brown.edu/pipermail/plt-scheme/2007-November/021272.html

Here is the relevant excerpt:
A quick and correct response! Indeed it seems like FreeBSD 7 has
changed the behavior to be SIGSEGV instead of SIGBUS.

And they have the same problem (old binaries won't work). I
wonder if there are other ports that use GC of some sort are
broken by this change.

Please, try the patch below and report whether it is enough to fix cmucl
and any other regressions.

That patch will fix the problem. Also note that the same
change is required on i386.

The /* XXX hack */ comment in the original -7 code seems to
indicates the change to override the signal value returned by
page_pfault() was not fully thought through. So I believe
your unbreaking change should be incorporated in the 7
release.
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Serious compatibility breakage in -current.
    ... FreeBSD 7 has changed the protection violation signal from SIGBUS to ... FreeBSD system, protection violations cause a SIGSEGV to be delivered ... SIGSEGV in response to page protection violations. ...
    (freebsd-current)
  • Serious compatibility breakage in -current.
    ... FreeBSD 7 has changed the protection violation signal from SIGBUS to ... FreeBSD system, protection violations cause a SIGSEGV to be delivered ... SIGSEGV in response to page protection violations. ...
    (freebsd-current)
  • Re: Xsane
    ... >>I've got a problem running Xsane on freebsd 5.3. ... There are a lot of libs missing. ... SIGNAL 11 (SIGSEGV) ...
    (comp.unix.bsd.freebsd.misc)
  • FreeBSD Security Advisory FreeBSD-SA-03:09.signal
    ... For general information regarding FreeBSD Security Advisories, ... Signals are a UNIX mechanism for handling asynchronous events such as ... It has never been included in the kernel installed by ... a malicious local user could use this vulnerability ...
    (Bugtraq)
  • [Full-Disclosure] FreeBSD Security Advisory FreeBSD-SA-03:09.signal
    ... For general information regarding FreeBSD Security Advisories, ... Signals are a UNIX mechanism for handling asynchronous events such as ... It has never been included in the kernel installed by ... a malicious local user could use this vulnerability ...
    (Full-Disclosure)