Re: Not running into expected SIGSEGV

[Thomas Schwinge]

Hi!

Samuel's MTA (labri.fr) told me that it's "not permissible" to attach
*.exe* files to emails.  I you didn't receive that file, you can also
copy it from darnassus:~tschwinge/stack_check1.exe, or ask me to send it
"scrambled".

On Tue, 23 Feb 2016 11:37:58 +0100, I wrote:
> 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

signature.asc
Description: PGP signature