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

[Kevin Smith]

...I added the process book keeping code that I found at the bottom of the
opengl-ffi.lisp example to my program, namely:

(progn
  (ccl:process-run-function
   "housekeeping"
   #'ccl::housekeeping-loop)
  (ccl:process-interrupt
   ccl::*initial-process*
   (lambda ()
     ;; CCL::%SET-TOPLEVEL is sort of like PROCESS-PRESET for the
     ;; initial process; CCL::TOPLEVEL is sort of like PROCESS-RESET
     ;; for that process.
     (ccl::%set-toplevel
      (lambda ()
       ;;; Set the OSX Window Server's notion of the name of the
       ;;; current process.
       (rlet ((psn #>ProcessSerialNumber))
         (#_GetCurrentProcess psn)
         (with-cstrs ((name "simple OpenGL example"))
           (ccl::external-call "_CPSSetProcessName" :address psn :address
name :void)))
       (ccl::%set-toplevel nil)
       (main)))
     (ccl::toplevel))))

..in addition to hacks mentioned below.  I got the window to come up and
display my OpenGL graphics, but the GLUT event loop seems to be hanging
(which I use cl-glut to access).

So, further progress - I am guessing from this adventure that there are  not
many user's of cl-opengl on clozure because it doesn't work :-)..

I'm not a huge fan of glut so, maybe ultimately it would be better to port
my work to one of the toolkits already supported by CCL and it's native ffi
open-gl, but that is a lot of work for me right now and I think it makes it
more difficult for me to go back to SBCL should I choose to use that
environment....I'll have to give it some thought.  I am definitely suffering
a bit with swig and interfacing with C++ code right now through CFFI
(although I must admit, I really do like the cl-opengl interface for it's
elegance - different topic). If CCL makes interfacing with C++ a little
easier through it's FFI database, then maybe another reason for me to look
into it....



On Mon, Aug 2, 2010 at 9:41 AM, Kevin Smith <k2msmith at gmail.com> wrote:

> 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/69cbd1e9/attachment.html>