[Openmcl-devel] segfault on open-shared-library libobjc.so on gentoo 64-bit with ccl-1.8

Gary Byers gb at clozure.com
Tue Jun 5 17:16:09 UTC 2012


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

has some information about attaching GDB to a running CCL process; if
you really want to debug a problem in a shared library's
initialization code, you'll find that using GDB to do so would be
a lot easier than trying to do so without GDB (though even with GDB,
the library's source code, and an understanding of what the library's
initialization code does. debugging problems like this can be somewhat
daunting.)

Googling for the string "gc_push_all_eager" yields a few thousand hits
(many of which contain the string "segfault" but are not otherwise 
enlightening.) Googling for "gc_push_all_eager gc_init" yields about
half as many entries, some of which claim that GC_init() crashes unless
it's called from the main thread.  I don't know whether your library's
initialization code calls GC_init() or not, but it's certainly plausible
that it does.  (GC_init() is part of Hans Boehm's conservative GC.)

On OSX, some libraries execute breakpoint instructions if they find that
they're being initialized on some thread other than the one that they
expect to be; for some reason, people kept reporting that to us.  To
try to stop that (the fairly steady stream of bug reports), we effectively
made OPEN-SHARED-LIBRARY always open the library on the initial thread.
OPEN-SHARED-LIBRARY takes a second argument which can be provided as
a PROCESS object or as one of the keywords :INITIAL or :CURRENT, and this
argument defaults to :INITIAL on OSX and to :CURRENT on OSes that don't
leave breakpoint instructions in shipping code.  You might try:

? (open-shared-library whatever :initial)

and if that works there'd be reason to believe that the GC_init bug is still
present (at least in whatever version of libobjc you have installed.)

I tried loading a few different versions of libobjc on a fairly up-to-date
Ubuntu system and didn't see any problems but that isn't really conclusive.

Even if the library loads, I'd be a little leery of using it unless I was
pretty confident that any GC strategy it uses can find the bounds of threads'
stacks.

Aside from the fact that the builtin REPL and SLIME's don't usually run on
the initial thread, it's not clear that this has much to do with CCL.

On Tue, 5 Jun 2012, Pascal J. Bourguignon wrote:

> "Pascal J. Bourguignon" <pjb at informatimago.com> writes:
>
>> When I try to load libobjc.so on gentoo 64-bit with ccl-1.8, it
>> sigsegfauls.  What can I do to debug that?
>>
>>
>> cl-user> (ccl:open-shared-library "libobjc.so")
>>
>>
>> [pjb at kuiper :0 tmp]$ ls -l /usr/lib/libobjc.so
>> lrwxrwxrwx 1 root root 12 Apr 16 13:07 /usr/lib/libobjc.so -> libobjc.so.4*
>> [pjb at kuiper :0 tmp]$ file /usr/lib/libobjc.so.4
>> /usr/lib/libobjc.so.4: symbolic link to `libobjc.so.4.6.0'
>> [pjb at kuiper :0 tmp]$ file /usr/lib/libobjc.so.4.6.0
>> /usr/lib/libobjc.so.4.6.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
>
>
> Note: opening version 2 works well.
>
> cl-user> (ccl:open-shared-library "/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc.so")
> #<shlib libobjc.so.2 #x302001E5677D>
>
> [pjb at kuiper :0 tmp]$ ls -l /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc*
> -rw-r--r-- 1 root root 208378 Mar 27 21:02 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc.a
> -rwxr-xr-x 1 root root    960 Mar 27 21:02 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc.la*
> lrwxrwxrwx 1 root root     16 Mar 27 21:03 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc.so -> libobjc.so.2.0.0*
> lrwxrwxrwx 1 root root     16 Mar 27 21:03 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc.so.2 -> libobjc.so.2.0.0*
> -rwxr-xr-x 1 root root 115536 Mar 27 21:02 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc.so.2.0.0*
> -rw-r--r-- 1 root root 501050 Mar 27 21:02 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc_gc.a
> -rwxr-xr-x 1 root root    991 Mar 27 21:02 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc_gc.la*
> lrwxrwxrwx 1 root root     19 Mar 27 21:03 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc_gc.so -> libobjc_gc.so.2.0.0*
> lrwxrwxrwx 1 root root     19 Mar 27 21:03 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc_gc.so.2 -> libobjc_gc.so.2.0.0*
> -rwxr-xr-x 1 root root 274616 Mar 27 21:02 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc_gc.so.2.0.0*
> [pjb at kuiper :0 tmp]$ file /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc.so.2.0.0
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libobjc.so.2.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
>
> -- 
> __Pascal Bourguignon__                     http://www.informatimago.com/
> A bad day in () is better than a good day in {}.
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>



More information about the Openmcl-devel mailing list