[Openmcl-devel] CCL64 crash

[Gary Byers]

Well, I'm glad that this doesn't have anything at all to do with
CCL ...

Apple releases the source to the file that contains __CFInitialize():

<http://www.opensource.apple.com/source/CF/CF-550.13/CFRuntime.c>

That definition's a little ways past the middle of the file, and contains:

 	if (!pthread_main_np()) HALT;	// CoreFoundation must be initialized on the main thread

In other words, "if the CoreFoundation library's being initialized - perhaps
as a result of that library being loaded as a dependent of some other library -
and the current thread is not the initial thread, waste everyone's time by
executing a breakpoint instruction."  As I understand it, that check was
introduced in Snow Leopard.

(What did people do before Google ?)

You can force CoreFoundation to be initialized on the main thread by doing:

(let* ((s (make-semaphore)))
   (process-interrupt
     ccl::*initial-process*
     (lambda ()
       (open-shared-library
        "/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation")
       (signal-semaphore s)))
    (wait-on-semaphore s))

and then doing

(asdf::oos ...)   ; load the rest of the system

At times like this, I want to open the window and shout "It's the world's
most advanced operating system!"; sadly, the neighbors are heavily armed
and have told me repeatedly that they're tired of being awakened by this
news.



On Sat, 6 Feb 2010, Leo wrote:

> Hello Gary,
>
> On 6 February 2010 11:18, Gary Byers <gb at clozure.com> wrote:
>> 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.
>
> Thanks. Sorry I missed this point.
>
>> 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.
>>
>
> (open-shared-library "/usr/local/unix/plplot/lib/libplplotd.dylib")
> crashes ccl64.
>
> The log of the gdb session is attached.
>
> Thanks for your help.
>
> Leo
>