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