[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Segfault on armv5tel-linux-gnueabi
From: |
Ludovic Courtès |
Subject: |
Re: Segfault on armv5tel-linux-gnueabi |
Date: |
Thu, 23 Jun 2011 23:43:13 +0200 |
User-agent: |
Gnus/5.110017 (No Gnus v0.17) Emacs/24.0.50 (gnu/linux) |
Hi!
address@hidden (Ludovic Courtès) skribis:
> A bisect found that commit f60a7648d5926555c7760364a6fbb7dc0cf60720
> (v2.0.0-114-gf60a764) introduced a bug showing up on
> armv5tel-linux-gnueabi.
>
> The symptom is that ‘./check-guile threads.test’ segfaults. The
> backtrace I have so far isn’t very talkative:
The initial problem is a VM stack overflow, which leads to a segfault
because our stack overflow handling is so fragile. :-)
Running ‘meta/guile test-suite/tests/threads.test’ with a breakpoint at
‘scm_error’, we see:
--8<---------------cut here---------------start------------->8---
(gdb) thread apply all bt
[New Thread 0x44eee470 (LWP 19537)]
Thread 59 (Thread 0x44eee470 (LWP 19537)):
#0 0x405987b8 in clone () from
/nix/store/x7n64n36xpqbsi10lgpr3x9f1z9jsp83-glibc-2.12.2/lib/libc.so.6
#1 0x40144fe0 in T.337 () from
/nix/store/x7n64n36xpqbsi10lgpr3x9f1z9jsp83-glibc-2.12.2/lib/libpthread.so.0
#2 0x00000000 in ?? ()
Thread 58 (Thread 0x44630470 (LWP 19536)):
#0 scm_error (key=0xc7060, subr=0x0, message=0x402a253c "Stack overflow",
args=0x4, rest=0x4) at ../../libguile/error.c:61
#1 0x40255be0 in scm_report_stack_overflow () at ../../libguile/stackchk.c:58
#2 0x4027a62c in scm_c_vm_run (vm=0x14a9a8, program=0x708e8, argv=0x4462fcc8,
nargs=4) at ../../libguile/vm.c:564
#3 0x401ec344 in scm_call_4 (proc=0x708e8, arg1=<value optimized out>,
arg2=<value optimized out>, arg3=<value optimized out>, arg4=0x301c40) at
../../libguile/eval.c:506
#4 0x40262b2c in scm_catch_with_pre_unwind_handler (key=0x404, thunk=0x301c60,
handler=0x301c50, pre_unwind_handler=0x301c40) at ../../libguile/throw.c:86
#5 0x401e3380 in scm_i_with_continuation_barrier (body=0x401e2bdc <c_body>,
body_data=0x4462fd4c, handler=0x401e2eb0 <c_handler>, handler_data=0x4462fd4c,
pre_unwind_handler=0x401e2d10 <pre_unwind_handler>,
pre_unwind_handler_data=0xda340) at ../../libguile/continuations.c:450
#6 0x401e3440 in scm_c_with_continuation_barrier (func=<value optimized out>,
data=<value optimized out>) at ../../libguile/continuations.c:546
#7 0x401142d8 in GC_call_with_stack_base () from
/nix/store/iva9d3m74d1sw2ymas27kacnj2k3rp81-boehm-gc-7.2pre20110122/lib/libgc.so.1
#8 0x402608f8 in scm_i_with_guile_and_parent (func=<value optimized out>,
data=<value optimized out>) at ../../libguile/threads.c:917
#9 scm_with_guile (func=<value optimized out>, data=<value optimized out>) at
../../libguile/threads.c:923
#10 0x401142d8 in GC_call_with_stack_base () from
/nix/store/iva9d3m74d1sw2ymas27kacnj2k3rp81-boehm-gc-7.2pre20110122/lib/libgc.so.1
#11 0x4026061c in on_thread_exit (v=0x389a80) at ../../libguile/threads.c:714
#12 0x40144348 in __nptl_deallocate_tsd () from
/nix/store/x7n64n36xpqbsi10lgpr3x9f1z9jsp83-glibc-2.12.2/lib/libpthread.so.0
#13 0x40151ea4 in ?? () from
/nix/store/x7n64n36xpqbsi10lgpr3x9f1z9jsp83-glibc-2.12.2/lib/libpthread.so.0
#14 0x40151ea4 in ?? () from
/nix/store/x7n64n36xpqbsi10lgpr3x9f1z9jsp83-glibc-2.12.2/lib/libpthread.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 4 (Thread 0x43dff470 (LWP 19482)):
#0 0x4014e314 in read () from
/nix/store/x7n64n36xpqbsi10lgpr3x9f1z9jsp83-glibc-2.12.2/lib/libpthread.so.0
#1 0x4014dba4 in __pthread_enable_asynccancel () from
/nix/store/x7n64n36xpqbsi10lgpr3x9f1z9jsp83-glibc-2.12.2/lib/libpthread.so.0
#2 0x00000000 in ?? ()
Thread 1 (Thread 0x4016e000 (LWP 19479)):
#0 0x405987b8 in clone () from
/nix/store/x7n64n36xpqbsi10lgpr3x9f1z9jsp83-glibc-2.12.2/lib/libc.so.6
#1 0x40144fe0 in T.337 () from
/nix/store/x7n64n36xpqbsi10lgpr3x9f1z9jsp83-glibc-2.12.2/lib/libpthread.so.0
#2 0x44eee6a4 in ?? ()
#3 0x44eee6a4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
--8<---------------cut here---------------end--------------->8---
Commenting out the 5 tests from threads.test that invoke ‘cancel-thread’
solves the problem.
Looks like a déjà vu. To be continued...
Ludo’.