Not running into expected SIGSEGV

[Thomas Schwinge]

Hi!

The attached program, stack_check1.exe, is supposed to terminated with a
SIGSEGV (endless recursion, if I remember correctly the Ada source code
From the GCC testsuite).  (Samuel, that's the issue that I vaguely/in a
hurry described to you at FOSDEM, which impacts my GCC testing.)

I do get the SIGSEGV with old 1:0.6.git20150704-2 Hurd packages
installed, in a system that is otherwise up to date.  Booting with more
recent Hurd packages from <http://snapshot.debian.org/binary/hurd/>
installed, the stack_check1.exe process then just hangs.  (Need to kill
-KILL it, C-c will make the session/PTY hang or something.)  If I
remember correctly (it's been some months...), there also was erratic
behavior to be observed when I bisected earlier Hurd package versions:
some worked (SIGSEGV) some didn't (hang).

I couldn't figure out any pattern from looking at the diffs between the
respective Hurd packages' sources.  What I did not consider is which
glibc versions the Hurd packages have been built against (statically
linked, in part) -- which might be relevant, too.

With recent 1:0.7.git20160214-2 Hurd packages installed:

    $ ./stack_check1.exe
    [hangs]

    $ rpctrace ./stack_check1.exe
    [...]
    task51(pid1023)->vm_map (0 2097152 0 1  (null) 0 1 0 7 1) = 0 196608
    task51(pid1023)->vm_deallocate (196608 851968) = 0 
    task51(pid1023)->vm_deallocate (2097152 196608) = 0 
    task51(pid1023)->vm_protect (1048576 135168 0 3) = 0 
    task51(pid1023)->mach_port_deallocate (pn{ 24}) = 0 
    task51(pid1023)->mach_port_deallocate (pn{ 24}) = 0 
      68<--72(pid-1)-> 2400 (rpctrace: ../../utils/rpctrace.c:863: 
print_contents: Assertion `inp->msgh_bits & 0x80000000U' failed.
    Aborted

(Yay, another rpctrace issue.)  ;-)

    $ gdb -q ./stack_check1.exe
    Reading symbols from ./stack_check1.exe...done.
    (gdb) r
    Starting program: /media/erich/home/thomas/stack_check1.exe 
    [New Thread 1026.5]
    [New Thread 1026.6]
    
    Program received signal SIGSEGV, Segmentation fault.
    0x0107d92c in mach_msg_trap () at 
/build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
    2       
/build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S: 
No such file or directory.
    (gdb) info threads
      Id   Target Id         Frame 
      6    Thread 1026.6     0x080614ec in stack_check1.consume_stack ()
      5    Thread 1026.5     0x0107d92c in mach_msg_trap () at 
/build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
    * 4    Thread 1026.4     0x0107d92c in mach_msg_trap () at 
/build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
      3    bogus thread id 3 Can't fetch registers from thread bogus thread id 
3: No such thread

(Yay, another GDB issue.)  ;-)

    (gdb) thread apply all bt
    
    Thread 6 (Thread 1026.6):
    #0  0x080614ec in stack_check1.consume_stack ()
    #1  0x08061540 in stack_check1.consume_stack ()
    #2  0x08061540 in stack_check1.consume_stack ()
    #3  0x08061540 in stack_check1.consume_stack ()
    #4  0x08061540 in stack_check1.consume_stack ()
    #5  0x08061540 in stack_check1.consume_stack ()
    #6  0x08061540 in stack_check1.consume_stack ()
    #7  0x08061540 in stack_check1.consume_stack ()
    [...]
    #251 0x08061540 in stack_check1.consume_stack ()
    #252 0x08061540 in stack_check1.consume_stack ()
    #253 0x08061540 in stack_check1.consume_stack ()
    #254 0x08061639 in stack_check1.t ()
    #255 0x08060f72 in system.tasking.stages.task_wrapper (self_id=0x8082eb0) 
at s-tassta.adb:1262
    #256 0x01042b1f in entry_point (self=0x8085fb0, start_routine=0x8060e20 
<system.tasking.stages.task_wrapper>, arg=0x8082eb0)
        at ./pthread/pt-create.c:64
    #257 0x00000000 in ?? ()
    
    Thread 5 (Thread 1026.5):
    #0  0x0107d92c in mach_msg_trap () at 
/build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
    #1  0x0107e0c6 in __mach_msg (msg=0x2802f20, option=3, send_size=32, 
rcv_size=4096, rcv_name=56, timeout=0, notify=0) at msg.c:110
    #2  0x0107e704 in __mach_msg_server_timeout (demux=0x108e4c0 
<msgport_server>, max_size=4096, rcv_name=56, option=0, timeout=0) at 
msgserver.c:150
    #3  0x0107e7c4 in __mach_msg_server (demux=0x108e4c0 <msgport_server>, 
max_size=4096, rcv_name=56) at msgserver.c:195
    #4  0x0108e5ae in _hurd_msgport_receive () at msgportdemux.c:67
    #5  0x01042b1f in entry_point (self=0x80819b0, start_routine=0x108e550 
<_hurd_msgport_receive>, arg=0x0) at ./pthread/pt-create.c:64
    #6  0x00000000 in ?? ()
    
    Thread 4 (Thread 1026.4):
    #0  0x0107d92c in mach_msg_trap () at 
/build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
    #1  0x0107e0c6 in __mach_msg (msg=0x20039e8, option=2, send_size=0, 
rcv_size=24, rcv_name=49, timeout=0, notify=0) at msg.c:110
    #2  0x0104672d in __pthread_block (thread=0x8080e30) at 
../libpthread/sysdeps/mach/pt-block.c:35
    #3  0x01045ba3 in __pthread_cond_timedwait_internal (cond=0x8082564, 
mutex=0x8082578, abstime=0x0)
        at ../sysdeps/../libpthread/sysdeps/generic/pt-cond-timedwait.c:130
    #4  0x010458ae in __pthread_cond_wait (cond=0x8082564, mutex=0x8082578) at 
../sysdeps/../libpthread/sysdeps/generic/pt-cond-wait.c:36
    #5  0x08051c1c in system.task_primitives.operations.sleep 
(self_id=<optimized out>, reason=<optimized out>) at s-taprop.adb:574
    #6  0x08060603 in system.tasking.stages.activate_tasks 
(chain_access=0x2003af0) at s-tassta.adb:384
    #7  0x08061482 in stack_check1 ()

Thread 4 supposedly is hanging in some pthread function -- might that
give a clue, or (probably) is that just waiting for the "worker" thread 6
to finish?  (I mean, thread 6 should hit the SIGSEGV regardless of what
thread 4 is doing.)


Grüße
 Thomas

stack_check1.exe.xz
Description: application/xz

signature.asc
Description: PGP signature