[Openmcl-devel] Trace/BPT trap with cl-opengl loading

[Kevin Smith]

thank you I will give this a try in the morning..By the way, I was able to trace my problem with cl-opengl a little further to the cffi function:

(cffi:load-foreign-library '(:framework "OpenGL))  (called from the libraries.lisp file in cl-opengl package)

I manually tried this call in the repl outside of the cl-opengl package and it  also crashes.  checked my *darwin-framework-directories* variable and that seems OK. then I found, you can enter the full path of the framework (library ?) directly, like so:

(cffi:load-foreign-library "/System/Library/Frameworks/OpenGL.framework/OpenGL")

That also crashes it.

Incidentally, the same call worked OK with other non-framework libraries that I tried, like /usr/lib/libm.dylib...

but I'll look at your suggestion more closely..  I use this library in sbcl without a problem...(but have other problems with sbcl on the mac).

-K


On Aug 1, 2010, at 8:02 PM, Gary Byers wrote:

> Apple decided to enforce the restriction that some shared libraries (I don't
> remember which one(s)) only be initialized on the initial thread of the OS-level
> process by executing a breakpoint instruction.  (It's the World's Most Advanced
> Operating System!)  That breakpoint causes the process to terminate with the
> message you're seeing when the library in question is loaded (directly or as
> the result of loading some library which depends on it) from a CCL listener
> thread (or a SLIME REPL thread, or ... any thread other than the initial
> one.)
> 
> The general workaround is to replace:
> 
> (open-shared-library "culprit.dylib")
> 
> with
> 
> (run-in-initial-thread-and-wait-until-done
>  (lambda () (open-shared-library "culprit.dylib")))
> 
> There are a few issues:
> 
> 1) The affected code may be in a third-party lisp library; it'd be good if
>   the authors of such libraries made the necessary changes so that people
>   didn't keep running into this.
> 
> 2) It can be hard to know which libraries are affected.  I think that the
>   actual check-and-breakpoint is in the initialization code for the
>   CoreFoundation library; whether that's correct or not, it's in some
>   library that's used by many other things on OSX, so the rule of thumb
>   is something like "when in doubt, force library loading to happen on
>   the initial thread  in OSX."
> 
> 3) There are several ways to do what I'm calling
>   RUN-IN-INITIAL-THREAD-AND-WAIT-UNTIL-DONE; I don't think that we yet
>   offer a standard way of doing this (though CCL::CALL-IN-INITIAL-PROCESS
>   us present in recent versions of the trunk and is intended to become
>   an exported/documented/standard interface in the near future.)
> 
>   We changed some of our examples when this "check and breakpoint" behavior
>   was introduced (in 10.6, IIRC); see "ccl:examples;opengl-ffi.lisp", for
>   instance.
> 
> 4) I'd want to think about this more than I have, but at the moment I can't
>   think of a reason for OPEN-SHARED-LIBRARY not to at least default to
>   doing what it does on the initial thread by default.
> 
> 
> 
> On Sun, 1 Aug 2010, Kevin Smith wrote:
> 
>> The only hurdle for me for trying out (and maybe switching) to clozure on the mac platform is that I can't seem to get the
>> cl-opengl package loaded.  I get the error:  "Trace/BPT trap" when I try to load that package.  (All other dependent packages
>> like cffi, loaded successfully).
>> I am using ccl64,  version 1.5 on Darwin/MAC OS  (DarwinX8664).  Latest version of cl-opengl.
>> I believe I also tried it on the 32-bit ccl.  Same problem.  It looks like it only compiles a few source files in the
>> cl-opengl package before it dies.
>> If someone can point out to me how I can trace this to provide more information on where it is crashing or maybe someone has
>> run across this already with this particular package.
>> Thanks,
>> Kevin
>>