[Openmcl-devel] CCL64 crash

[Gary Byers]

The section named "Loading GDB init file" of

<http://trac.clozure.com/ccl/wiki/CclUnderGdb>

explains that it's necessary to load a GDB init file in order to tell
GDB what signals should be passed to the lisp and explains how to do
that.

If you don't do this, GDB will stop any time some thread in the target
process receives a a signal, even if that signal is routinely handled
in the lisp itself.  (as SIGUSR2 is on Darwin.)  That isn't too
interesting; seeing the environment when an unexpected and unhandled
exception happens may be much more interesting.

In #ccl, you (or someone else named "Leo") said someting about a
process terminating with a "Trace/BPT trap"; a couple of things
can cause this that I know of (including executing an "int $3"
debugger breakpoint when not running under a debugger.)  I'm
a little fuzzy on the details, but I believe that such a breakpoint
exists (or has recently existed) in some of Darwin's shared library
code, triggered by some slightly anomalous situation (like being
unable to find the right version of a dependent library for the
right architecture/word size.)  It's not quite as mundane as that,
but it's some situation where the shared library code can't or
doesn't quietly return failure, and I'm sure that I've run into
it in the relatively recent past.

In the times that I've seen this, I'm pretty sure that I've seen
a somewhat intelligible error message before the trap.

The first thing to do is to see if this has anything to do with
my fuzzy recollection of Apple's dynamic linker behavior or if
the problem's elsewhere.  If it is a case of what I'm thinking
of, you'd probably be able to reproduce it by doing:

? (open-shared-library "whatever") ; I don't know what libraries
                                    ; are opened in the code in
                                    ; question; figuring that out
                                    ; is left as an exerise.

If you do that in SLIME and it causes a trap, you might want
to look in the "inferior lisp" buffer (whatever it's called)
to see if an OS-level error message is sitting there ...

If the trap happens early in the ASDF build process, I'd at least
be suspicious of this explanation.  If all of the dependent libraries
load without incident ... well, I don't know where it's happening,
but running under GDB would tell us.  (It's really important to
load GDB's init file, like the Wiki page explains.)





On Sat, 6 Feb 2010, Leo wrote:

> Hello,
>
> After trying to fix a problem in using cl-plplot with help from rme in
> #lisp, I finally found a simple recipe to crash ccl64. It involves
> cl-plplot. So,
>
> 1. Install cl-plplot with plplot compiled with:
>   cmake -DCMAKE_INSTALL_PREFIX=/usr/local/unix/plplot
>   -DENABLE_python=OFF -DENABLE_tcl=OFF -DENABLE_java=OFF
>   -DPLD_wxwidgets:BOOL=OFF
>   -DFREETYPE_INCLUDE_DIR:PATH=/usr/X11/include/freetype2/
>   -DWITH_FREETYPE:BOOL=ON -DENABLE_cxx=OFF
>   -DCMAKE_BUILD_TYPE:STRING=Debug
>   -DENABLE_DYNDRIVERS=OFF
>
>   Setting ENABLE_DYNDRIVERS=OFF is key
>
> 2. start ccl64
>
> 3. (asdf:oos 'asdf:load-op :cl-plplot)
>
> CCL64 crashes.
>
> Below is the bt caught in gdb.
>
> --------------------------------
> (gdb) attach 390
> Attaching to process 390.
> 0x00007fff834fb9ee in __semwait_signal ()
> (gdb) c
> Continuing.
>
> Program received signal SIGUSR2, User defined signal 2.
> 0x00007fff834fb9ee in __semwait_signal ()
> (gdb) bt
> #0  0x00007fff834fb9ee in __semwait_signal ()
> #1  0x00007fff834fb87d in nanosleep ()
> #2  0x000000000001b102 in SPffcall () at ../x86-spentry64.s:4042
> #3  0x000000000044bf98 in ?? ()
> #4  0x000000000044bf98 in ?? ()
> (gdb) bt full
> #0  0x00007fff834fb9ee in __semwait_signal ()
> No symbol table info available.
> #1  0x00007fff834fb87d in nanosleep ()
> No symbol table info available.
> #2  0x000000000001b102 in SPffcall () at ../x86-spentry64.s:4042
> No symbol table info available.
> #3  0x000000000044bf98 in ?? ()
> No symbol table info available.
> #4  0x000000000044bf98 in ?? ()
> No symbol table info available.
> (gdb)
> --------------------------------
>
> Leo
>
> -- 
> H A P P Y  H O L I D A Y S!
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>