[bug-libsigsegv] libsigsegv on Haiku

[Eric Blake]

Stock libsigsegv 2.9 does nothing on Haiku, skipping all 5 tests:

libsigsegv: i586-pc-haiku | no | no | 2.9

But with this minor patch:

diff --git c/configure.ac i/configure.ac
index 760c519..281dce1 100644
--- c/configure.ac
+++ i/configure.ac
@@ -580,7 +580,7 @@ else
           ;;
       esac
       ;;
-    beos*)
+    beos* | haiku*)
       case "$host_cpu" in
         i?86 | x86_64) CFG_FAULT=fault-beos-i386.h ;;
         *) CFG_FAULT=fault-beos.h ;;
@@ -664,7 +664,7 @@ else
   case "$host_os" in
     linux*)                CFG_STACKVMA=stackvma-linux.c ;;
     freebsd* | dragonfly*) CFG_STACKVMA=stackvma-freebsd.c ;;
-    beos*)                 CFG_STACKVMA=stackvma-beos.c ;;
+    beos* | haiku*)        CFG_STACKVMA=stackvma-beos.c ;;
     macos* | darwin*)      CFG_STACKVMA=stackvma-mach.c ;;
   esac
 fi


it changes to:

libsigsegv: i586-pc-haiku | no | yes | 2.9

but it still skips four tests, and for stackoverflow1, it causes a modal
popup box saying:

The application:
  ./stackoverflow1
has encountered an error which prevents it from continuing. Haiku will
terminate the application and clean up.
Debug/OK

prior to failing the test.

I've dug around a bit more; the (minimally documented) 3-arg handler
interface (similar to BeOS) that uses a struct vregs as the third
argument can access %esp (struct vregs._reserved_1), %eip, and the
various general purpose registers (%eax, %ebx, ...) of the old stack
prior to the signal, but not any protected registers such as %cr2.
Haiku does not yet support the POSIX interface of SA_SIGINFO.  So short
of reading raw instructions from *esp, then calculating the resulting
address from the remaining general purpose registers (in short, writing
a subset of an x86 disassembler), I don't see any way to get at the
faulting address, so that means we have to continue to live without
HAVE_SIGSEGV_RECOVERY without further help from the Haiku devs.

On the other hand, Haiku does support both conditions B and C, and thus
can define HAVE_STACK_OVERFLOW_RECOVERY (condition A of an accurate
fault address is the same problem as accurate SIGSEGV recovery above;
condition B is SIGSEGV_FAULT_STACKPOINTER which is the esp portion of
struct vregs, and condition C is that stackvma can iterate over virtual
memory regions using the BeOS interface of get_next_area_info).
However, the reason that the stackoverflow1 test fails is that the stack
pointer at the time of the crash is further than 1 page away from the
edge of what vma claimed was mapped.  I instrumented the program
further, and get this output:

alternate stack installed
handler installed
Starting recursion pass 1.
entering handler
probing for vma containing 0x7ffeffff
got 0x7efef000,0x7fff0000 as original stack bounds
rlimit size 0x1000000
comparing old esp 0x7eff2ffc with stack bounds

so the stack overflow was reliably detected, but the stack pointer was
nearly four pages away from the bounds of the vma region, which was
beyond the 1 page threshold that handler-unix.c was looking for when
declaring a stack overflow instead of re-raising SIGSEGV.

I'm not sure if relaxing the check for whether the old stack pointer is
with 4 pages and/or 1% of the end of the rlimit size of the stack would
be appropriate for all platforms, but it seems like it would solve the
problem of reliable stack overflow detection in libsigsegv for Haiku.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature