SIGSEGV for address 0 access from libthr.so in handle_signal

[nbriggs]

I'm not 100% sure this is a valgrind problem, but --

pid 82335 (memcheck-x86-freebs): sigreturn mc_flags 762db36
pid 82335 (memcheck-x86-freebs): sigreturn mc_flags 762db36
==82335== Invalid read of size 4
==82335==    at 0x7812B9B: ??? (src/lib/libthr/thread/thr_sig.c:207)
==82335==    by 0x781216F: ??? (src/lib/libthr/thread/thr_sig.c:191)
==82335==    by 0x38184E13: ??? (in /usr/local/lib/valgrind/memcheck-x86-freebsd)
==82335==    by 0x4514BE: start_lisp (main.c:690)
==82335==    by 0x450F30: main (main.c:637)
==82335==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==82335== 
==82335== 
==82335== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==82335==  Access not within mapped region at address 0x0
==82335==    at 0x7812B9B: ??? (src/lib/libthr/thread/thr_sig.c:207)
==82335==    by 0x781216F: ??? (src/lib/libthr/thread/thr_sig.c:191)
==82335==    by 0x38184E13: ??? (in /usr/local/lib/valgrind/memcheck-x86-freebsd)
==82335==    by 0x4514BE: start_lisp (main.c:690)
==82335==    by 0x450F30: main (main.c:637)
==82335==  If you believe this happened as a result of a stack
==82335==  overflow in your program's main thread (unlikely but
==82335==  possible), you can try to increase the size of the
==82335==  main thread stack using the --main-stacksize= flag.
==82335==  The main thread stack size used in this run was 16777216.
==82335== 
==82335== HEAP SUMMARY:
==82335==     in use at exit: 269,926,595 bytes in 522 blocks
==82335==   total heap usage: 1,153 allocs, 631 frees, 270,489,046 bytes allocated
==82335== 
==82335== LEAK SUMMARY:
==82335==    definitely lost: 4,072 bytes in 6 blocks
==82335==    indirectly lost: 0 bytes in 0 blocks
==82335==      possibly lost: 0 bytes in 0 blocks
==82335==    still reachable: 269,922,523 bytes in 516 blocks
==82335==         suppressed: 0 bytes in 0 blocks
==82335== Rerun with --leak-check=full to see details of leaked memory
==82335== 
==82335== Use --track-origins=yes to see where uninitialised values come from
==82335== For lists of detected and suppressed errors, rerun with: -s
==82335== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault

This fault doesn't happen if the program is run without valgrind. I recompiled libthr.so with debug info, and it seems to be failing in libthr's handle_signal (thr_sig.c:207) doing

        /* add previous level mask */
    SIGSETOR(actp->sa_mask, ucp->uc_sigmask);

[nbriggs]

Looking at the vgcore file it dropped

(gdb) disass 0x07812b80,+40   # start of handle_signal
Dump of assembler code from 0x7812b80 to 0x7812ba8:
   0x07812b80:  push   %ebp
   0x07812b81:  mov    %esp,%ebp
   0x07812b83:  push   %ebx
   0x07812b84:  push   %edi
   0x07812b85:  push   %esi
   0x07812b86:  and    $0xfffffff0,%esp
   0x07812b89:  sub    $0x2e0,%esp
   0x07812b8f:  mov    %ecx,%edi
   0x07812b91:  mov    0xc(%ebp),%ecx
   0x07812b94:  mov    %gs:0x8,%esi
=> 0x07812b9b:  mov    (%ecx),%eax
   0x07812b9d:  or     %eax,0x8(%edi)
   0x07812ba0:  mov    0x4(%ecx),%eax
   0x07812ba3:  or     %eax,0xc(%edi)
   0x07812ba6:  mov    0x8(%ecx),%eax
End of assembler dump.
(gdb) info r
eax            0x763ea10           123988496
ecx            0x0                 0
edx            0x1a                26
ebx            0x781ee2c           125955628
esp            0xfbbfdb00          0xfbbfdb00
ebp            0xfbbfddf0          0xfbbfddf0
esi            0x8000030           134217776
edi            0xfbbfde00          -71311872
eip            0x7812b9b           0x7812b9b
eflags         0x200084            [ PF SF ID ]
cs             0x33                51
ss             0x3b                59
ds             0x3b                59
es             0x0                 0
fs             0x0                 0
gs             0xb                 11
fs_base        <unavailable>
gs_base        <unavailable>
(gdb) 

[paulfloyd]

Over 1 year for a 1 line code change. Hope it was worth the wait.