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