[Openmcl-devel] CCL64 crash
gb at clozure.com
Sat Feb 6 13:10:32 UTC 2010
Well, I'm glad that this doesn't have anything at all to do with
Apple releases the source to the file that contains __CFInitialize():
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)))
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
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
>> 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
>> 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.
More information about the Openmcl-devel