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

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Fri May 8 05:42:33 EDT 2009

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?

At Fri, 8 May 2009 00:09:05 -0700, YC wrote:
> Hi Matthew -
> 
> It didn't take too long to produce a core dump.  It appears to crash at
> uncopy_stack in setjumpup.c.
> 
> Core was generated by `/usr/local/plt/bin/mzscheme'.
> Program terminated with signal 11, Segmentation fault.
> #0  uncopy_stack (ok=0, b=0xb3e3ec88, prev=0xbeff511c) at
> ./../src/setjmpup.c:329
> 329     {
> (gdb) print *b
> $1 = {stack_from = 0x0, stack_copy = 0x0, stack_size = 0, stack_max_size =
> 0, cont = 0x0, buf = {jb = {{jb = {{__jmpbuf = {
>               0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val
> = {0 <repeats 32 times>}}}},
>         stack_frame = 0}}, gcvs = 0, gcvs_cnt = 0}, gc_var_stack = 0x0,
> external_stack = 0x0}
> (gdb) print *prev
> $2 = 0
> (gdb)
> 
> Below is the backtrace.  Does this provide you with some details of what
> this could be?  What else can I help look for?
> 
> This is v4.1.3 if that makes a difference.  Thanks,
> yc
> 
> #0  uncopy_stack (ok=0, b=0xb3e3ec88, prev=0xbeff511c) at
> ./../src/setjmpup.c:329
> #1  0x08136967 in uncopy_stack (ok=<value optimized out>, b=0xb3e3ec88,
> prev=0xbeff547c) at ./../src/setjmpup.c:339
> #2  0x08136967 in uncopy_stack (ok=<value optimized out>, b=0xb3e3ec88,
> prev=0xbeff57dc) at ./../src/setjmpup.c:339
> #3  0x08136967 in uncopy_stack (ok=<value optimized out>, b=0xb3e3ec88,
> prev=0xbeff5b3c) at ./../src/setjmpup.c:339
> #4  0x08136967 in uncopy_stack (ok=<value optimized out>, b=0xb3e3ec88,
> prev=0xbeff5e9c) at ./../src/setjmpup.c:339
> #5  0x08136967 in uncopy_stack (ok=<value optimized out>, b=0xb3e3ec88,
> prev=0xbeff61fc) at ./../src/setjmpup.c:339
> #6  0x08136967 in uncopy_stack (ok=<value optimized out>, b=0xb3e3ec88,
> prev=0xbeff655c) at ./../src/setjmpup.c:339
> #7  0x08136967 in uncopy_stack (ok=<value optimized out>, b=0xb3e3ec88,
> prev=0xbeff68bc) at ./../src/setjmpup.c:339
> #8  0x08136967 in uncopy_stack (ok=<value optimized out>, b=0xb3e3ec88,
> prev=0xbeff6c1c) at ./../src/setjmpup.c:339
> #9  0x08136967 in uncopy_stack (ok=<value optimized out>, b=0xb3e3ec88,
> prev=0xbeff6f7c) at ./../src/setjmpup.c:339
> ..... (repeat) ...
> #14542 0x08136967 in uncopy_stack (ok=<value optimized out>, b=0xb3e3ec88,
> prev=0xbfbf0844) at ./../src/setjmpup.c:339
> #14543 0x081369bc in scheme_longjmpup (b=0xb3e3ec88) at
> ./../src/setjmpup.c:620
> #14544 0x0817a867 in do_swap_thread () at ./../src/thread.c:2516
> #14545 0x0817cd8e in scheme_thread_block (sleep_time=0) at
> ./../src/thread.c:4062
> #14546 0x08082b47 in scheme_do_eval (obj=0xadd35778, num_rands=1,
> rands=0xbfbf0f7c, get_value=-1) at ./../src/eval.c:7711
> #14547 0x0809ddef in apply_k () at ./../src/fun.c:2229
> #14548 0x080a7023 in scheme_top_level_do_worker (k=0x809dd70 <apply_k>,
> eb=1, new_thread=0, dyn_state=0x0)
>     at ./../src/fun.c:2068
> #14549 0x080a78a8 in scheme_top_level_do (k=0x809dd70 <apply_k>, eb=1) at
> ./../src/fun.c:1976
> #14550 0x08184316 in do_next_will (w=0xbeff511c) at ./../src/thread.c:6977
> #14551 0x081843c0 in will_executor_go (argc=1, argv=0xb4b24fac) at
> ./../src/thread.c:7045
> #14552 0x001128fa in ?? ()
> #14553 0x00000001 in ?? ()
> #14554 0xb4b24fac in ?? ()
> #14555 0x0960ea80 in ?? ()
> #14556 0x00622078 in ?? ()
> #14557 0xbfbf102c in ?? ()
> #14558 0x00000001 in ?? ()
> #14559 0x00000000 in ?? ()
> (gdb)


Posted on the users mailing list.