[Openmcl-devel] debugging a segfault

[Gary Byers]

Lisp faulted trying to access some low-level data associated with
a lisp process (possibly in order to print the process.)

You tried to do a backtrace, and the lisp kernel faulted trying
to access the same information.

My best guess is that we're trying to print information about
the dynamic state of a thread (its suspend-count) after that
thread has exited (or, perhaps, while it's exiting.)

Doing this safely (keeping the thread from exiting while we're
printing information about it) is certainly possible - we do
that while printing the PROCESS-WHOSTATE - but the whole idea
of printing dynamic state information is meaningless.  (At
best, it means "at some recent point in the past, the thread
had a whostate of X and a suspend-count of Y, but that doesn't
necessarily mean anything about its current state.")


On Mon, 2 Nov 2009, Jared C. Davis wrote:

> Hi,
>
> I'm running into a reproducible segfault during save-application on
> CCL 1.4-r13157M  (and at least some previous versions) on linux
> x86_64.
>
> I believe I have successfully followed the instructions for getting a
> backtrace in GDB, but I could be wrong. :)
>
> Here is what I get:
>
> CCL terminal:
>
>> Error: Fault during read of memory address #x7F60E68B78B8
>> While executing: CCL::LISP-THREAD-SUSPEND-COUNT, in process Initial(0).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
>
> 1 > :b
> *(7F56A25D5BF0) : 0 (LISP-THREAD-SUSPEND-COUNT #<LISP-THREAD
> liexception in foreign context
> Exception occurred while executing foreign code
> at atomic_incf_by + 16
> ? for help
> [15979] Clozure CL kernel debugger: r
> %rax = 0x0000000000000000      %r8  = 0x0000000000000000
> %rcx = 0x0000000000000000      %r9  = 0x00007fff56261180
> %rdx = 0x000030004001518b      %r10 = 0x00007f56a31ee6f0
> %rbx = 0x00007f60e68b77c0      %r11 = 0x0000000000000246
> %rsp = 0x00007fff56260c80      %r12 = 0x00007f60e68b78b8
> %rbp = 0x00007fff56261228      %r13 = 0x0000000000000001
> %rsi = 0x0000000000000001      %r14 = 0x0000000000000004
> %rdi = 0x00007f60e68b78b8      %r15 = 0x00007fff56261530
> %rip = 0x000000000041e230   %rflags = 0x00010202
>
>
> GDB terminal:
>
> $ gdb /home/jared/ccl/lx86cl64
> (gdb) source /home/jared/ccl/lisp-kernel/linuxx8664/.gdbinit
> (gdb) attach 15979
> Attaching to program: /home/jared/ccl/lx86cl64, process 15979
> ...
> (gdb) br *0x000000000041e230
> Breakpoint 2 at 0x41e230: file ../thread_manager.c, line 191.
> (gdb) continue
> Continuing.
>
> Breakpoint 2, atomic_incf_by (ptr=0x7f60e68b78b8, by=1)
>    at ../thread_manager.c:191
> 191	    old = *ptr;
> 1: x/i $pc
> 0x41e230 <atomic_incf_by+16>:	mov    (%r12),%rbx
> (gdb) bt
> #0  atomic_incf_by (ptr=0x7f60e68b78b8, by=1) at ../thread_manager.c:191
> #1  0x000000000041e3b0 in suspend_tcr (tcr=0x7f60e68b77c0)
>    at ../thread_manager.c:2074
> #2  0x000000000041f49b in lisp_suspend_tcr (tcr=0x7f60e68b77c0)
>    at ../thread_manager.c:2156
> #3  0x000000000041cdf6 in handle_exception (signum=<value optimized out>,
>    info=0x1, context=0x7fff56261180, tcr=0x7f56a31ee6f0, old_valence=0)
>    at ../x86-exceptions.c:1105
> #4  0x000000000041d229 in signal_handler (signum=4, info=0x7fff56261530,
>    context=0x7fff56261180) at ../x86-exceptions.c:1301
> #5  <signal handler called>
>
>
> At this point I seem in over my head.
>
> Thanks,
> Jared
>
> -- 
> Jared C. Davis <jared at cs.utexas.edu>
> 11410 Windermere Meadows
> Austin, TX 78759
> http://www.cs.utexas.edu/users/jared/
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>