[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Not running into expected SIGSEGV
From: |
Thomas Schwinge |
Subject: |
Not running into expected SIGSEGV |
Date: |
Tue, 23 Feb 2016 11:37:58 +0100 |
User-agent: |
Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/24.5.1 (i586-pc-linux-gnu) |
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
- Not running into expected SIGSEGV,
Thomas Schwinge <=
- Re: Not running into expected SIGSEGV, Thomas Schwinge, 2016/02/23
- Re: Not running into expected SIGSEGV, Samuel Thibault, 2016/02/23
- Re: Not running into expected SIGSEGV, Samuel Thibault, 2016/02/23
- Re: Not running into expected SIGSEGV, Justus Winter, 2016/02/23
- Re: Not running into expected SIGSEGV, Samuel Thibault, 2016/02/23
- Re: Not running into expected SIGSEGV, Justus Winter, 2016/02/23
- Re: Not running into expected SIGSEGV, Samuel Thibault, 2016/02/23
- Re: Not running into expected SIGSEGV, Samuel Thibault, 2016/02/23
Re: Not running into expected SIGSEGV, Justus Winter, 2016/02/23