[plt-scheme] how to trace a segmentation fault?

From: YC (yinso.chen at gmail.com)
Date: Fri May 8 14:11:58 EDT 2009

On Fri, May 8, 2009 at 2:42 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> This looks like trying to swap in a thread that is dead or whose
> representation has been overwritten with 0s due to memory corruption.
>
> What kinds of values are being finalized through will executors? The
> crash is happening during a will-procedure callback. We can't tell from
> the trace whether it's crashing before or after the procedure has done
> its job, but is it possible that the will-procedure runs some low-level
> finalizer that corrupts memory?
>

I grep through my source and didn't see any use of wills.  I grepped through
the dependent planet packages and didn't see any either.  Are there any
default wills used by mzscheme?

It might not have to do with wills, however, as I encountered a second core
dump and this had the different backtrace.  Perhaps it crashed after the
will callbacks?

Thanks,
yc

Program terminated with signal 11, Segmentation fault.
[New process 28895]
#0  uncopy_stack (ok=0, b=0xb44b00a0, prev=0xbf3602c0) at
./../src/setjmpup.c:329
329     {
#1  0x0813d2dc in uncopy_stack (ok=<value optimized out>, b=0xb44b00a0,
prev=0xbf360620) at ./../src/setjmpup.c:339
#2  0x0813d2dc in uncopy_stack (ok=<value optimized out>, b=0xb44b00a0,
prev=0xbf360980) at ./../src/setjmpup.c:339
#3  0x0813d2dc in uncopy_stack (ok=<value optimized out>, b=0xb44b00a0,
prev=0xbf360ce0) at ./../src/setjmpup.c:339
#4  0x0813d2dc in uncopy_stack (ok=<value optimized out>, b=0xb44b00a0,
prev=0xbf361040) at ./../src/setjmpup.c:339
#5  0x0813d2dc in uncopy_stack (ok=<value optimized out>, b=0xb44b00a0,
prev=0xbf3613a0) at ./../src/setjmpup.c:339
#6  0x0813d2dc in uncopy_stack (ok=<value optimized out>, b=0xb44b00a0,
prev=0xbf361700) at ./../src/setjmpup.c:339
#7  0x0813d2dc in uncopy_stack (ok=<value optimized out>, b=0xb44b00a0,
prev=0xbf361a60) at ./../src/setjmpup.c:339
#8  0x0813d2dc in uncopy_stack (ok=<value optimized out>, b=0xb44b00a0,
prev=0xbf361dc0) at ./../src/setjmpup.c:339
#9  0x0813d2dc in uncopy_stack (ok=<value optimized out>, b=0xb44b00a0,
prev=0xbf362120) at ./../src/setjmpup.c:339
... (repeat) ...
#14546 0x0813d2dc in uncopy_stack (ok=<value optimized out>, b=0xb44b00a0,
prev=0xbff5c768) at ./../src/setjmpup.c:339
#14547 0x0813d33c in scheme_longjmpup (b=0xb44b00a0) at
./../src/setjmpup.c:620
#14548 0x08183f9a in do_swap_thread () at ./../src/thread.c:2516
#14549 0x081869d1 in scheme_thread_block (sleep_time=0) at
./../src/thread.c:4062
#14550 0x08188da2 in scheme_out_of_fuel () at ./../src/thread.c:3524
#14551 0x080a49f0 in scheme_proc_struct_name_source (a=0xb44b0328) at
./../src/fun.c:3145
#14552 0x080a5777 in scheme_get_proc_name (p=0xb44b02f8, len=0xbff5cce4,
for_error=-1) at ./../src/fun.c:3201
#14553 0x0818abd8 in make_subprocess (child_thunk=0xb44b02f8,
child_start=0xbff5cd24, config=0xb49dd188, cells=0xb44b02d0,
---Type <return> to continue, or q <return> to quit---
    break_cell=0xb79304b8, mgr=0x0, normal_kill=1) at ./../src/thread.c:2868
#14554 0x0818ae63 in scheme_thread_w_details (thunk=0xb44b02f8, config=0x0,
cells=0x0, break_cell=0x0, mgr=0x0,
    suspend_to_kill=0) at ./../src/thread.c:3110
#14555 0x0818aeb9 in scheme_thread (thunk=0xb3426a08) at
./../src/thread.c:2904
#14556 0x0818ba4e in sch_thread (argc=1, args=0xb5d14f6c) at
./../src/thread.c:2912
#14557 0x00116ce6 in ?? ()
#14558 0x00000001 in ?? ()
#14559 0xb5d14f6c in ?? ()
#14560 0x08b814c0 in ?? ()
#14561 0x0032bcb3 in ?? ()
#14562 0xbff5cdcc in ?? ()
#14563 0x00000001 in ?? ()
#14564 0xb5d14f9c in ?? ()
#14565 0xb5dd9640 in ?? ()
#14566 0xb5d14f8c in ?? ()
#14567 0xbff5cdf4 in ?? ()
#14568 0x0011683a in ?? ()
#14569 0x0013a907 in ?? ()
#14570 0x00000000 in ?? ()
(gdb)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090508/db657698/attachment.html>

Posted on the users mailing list.