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

[Kevin Smith]

I had some chance to play around with this and got a little further, but not
much...

I added a hack in my code to do this as per the example file mentioned
below...

;;;(use-foreign-library opengl)
(eval-when (:compile-toplevel :load-toplevel :execute)
  (let* ((s (ccl:make-semaphore)))
    (ccl:process-interrupt ccl::*initial-process*
       (lambda ()
                         (ccl:open-shared-library "OpenGL.framework/OpenGL")
 (ccl:open-shared-library "GLUT.framework/GLUT")
 (ccl:signal-semaphore s)))
    (ccl:wait-on-semaphore s))

With this code, the shared libraries appear to load, but I do get the error
message:

kevin-mac-pro-3:lisp kevinsmith$ ccl64
; loading system definition from /Users/kevinsmith/ccl-lisp/babel/babel.asd
into #<Package "ASDF0">
; registering #<SYSTEM BABEL> as BABEL
; loading system definition from
/Users/kevinsmith/ccl-lisp/alexandria/alexandria.asd into #<Package "ASDF0">
; registering #<SYSTEM :ALEXANDRIA> as ALEXANDRIA
; loading system definition from
/Users/kevinsmith/ccl-lisp/trivial-features/trivial-features.asd into
#<Package "ASDF0">
; registering #<SYSTEM TRIVIAL-FEATURES> as TRIVIAL-FEATURES
Welcome to Clozure Common Lisp Version 1.5-dev-r13523M-trunk  (DarwinX8664)!
? (require :cl-opengl)
; Warning: Don't know how to setup a hook before saving cores on this Lisp.
; While executing: #<Anonymous Function #x302000D3A5DF>, in process
listener(1).
:CL-OPENGL
NIL
?

I created a stripped down version of my program that just has the cl-opengl
and GLUT libraries in it and it looks like the first window comes up, but
then it hangs before GL gets a chance to clear the window and do its
thing...  Is the warning  (the hook) the problem ?






On Sun, Aug 1, 2010 at 8:02 PM, Gary Byers <gb at clozure.com> 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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cl-opengl-devel/attachments/20100802/760f94b6/attachment.html>