[Openmcl-devel] Trace/BPT trap with cl-opengl loading
k2msmith at gmail.com
Sun Aug 1 23:53:16 CDT 2010
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:
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).
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
> The general workaround is to replace:
> (open-shared-library "culprit.dylib")
> (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
> 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.
More information about the Openmcl-devel