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 eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org