I think your original response on this was clear and reproducible from my perspective.. I would expect, though, that I would be getting the same trap error or some kind of exception under SBCL (I just built with threads - which I can verify with the sb-thread package) - but I'm not. Yes, I am running it under slime/emacs. I can send any additional info requested about my environment if anyone is interested.<div>
<br></div><div>By the way, I am a fairly new lisp user and my intent here was to describe a problem related to my out-of-the box experience trying to port my current application (which uses cl-opengl) to ccl64 which looked like a rather attractive alternative based on what appeared some fairly extensive support for the MAC platform - and it didn't work for the reasons described already. My apologies if this is not interesting to anyone else or if this is the wrong place to post this issue.</div>
<div><br></div><div><br></div><div><div><div class="gmail_quote">On Sat, Aug 7, 2010 at 12:40 AM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com">gb@clozure.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
On Fri, 6 Aug 2010, Kevin Smith wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
btw, I just tried the threaded version of sbcl (1.0.39) which I built from macports and it worked with no problems with all<br>
the same code (same cffi and cl-opengl packages), including my opencv libraries. I've not investigated what sbcl (or cffi)<br>
maybe doing that is different in this case, but it all seems to be working.<br>
</blockquote>
<br></div>
As I'm getting tired of saying and other people are likely tired of<br>
hearing - the bkpt trap happens when the CoreFoundation library is<br>
initialized on some thread other than the initial one. In CCL, the<br>
thread in which the REPL runs is not the initial thread; I assume that<br>
it is when SBCL's run from the shell. Depending on how SLIME's set up,<br>
a multithreaded SBCL running under SLIME will run SLIME's REPL on some<br>
non-initial thread. (Someone who's interested in and familiar with<br>
SBCL and SLIME can probably explain how to set things up if it doesn't<br>
work like this out of the box.) I assume that many people who run SBCL<br>
under SLIME run it this way (with SLIME's REPL running in its own thread);<br>
if you execute code that tries to open the CoreFoundation library in that<br>
thread, what would you expect to happen ?<br>
<br>
The source to a small C program is enclosed; it creates a thread and that<br>
thread tries to open CoreFoundation. If you compile that little program<br>
and run it (comments near the start of the file explain how), what do you<br>
think will happen ?<br>
<br>
I recognize that this is a little obscure and a little subtle. I have<br>
a lot of difficulty believing that it's -this- obscure or -this- subtle,<br>
and I really hope that the experiments (running the little C program,<br>
running SBCL in a SLIME REPL thread) will make this issue both crystal<br>
clear and completely uninteresting for you.<br>
<br>
I said earlier that CCL could help to keep people from running into<br>
this problem by making OPEN-SHARED-LIBRARY transparently open the<br>
library from the initial thread by default. I checked that change into<br>
the trunk a few minutes ago; I hope that it'll keep people from running<br>
into the problem and especially hope that it'll prevent them from<br>
thinking that it's interesting in some way.<div><div></div><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Thu, Aug 5, 2010 at 8:20 AM, Gary Byers <<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>> wrote:<br>
The "trace/bkpt trap" happens - as you've already confirmed - when<br>
a thread other than the initial thread tries to open/initialize<br>
a particular shared library. (I'm fairly sure that the library<br>
in question is CoreFoundation, which is used by many other things<br>
on OSX.)<br>
<br>
Alex's XMLisp stuff runs on top of CCL's Cocoa environment, which<br>
takes great care to ensure that the Cocoa framework (and therefore<br>
CoreFoundation) are loaded on the initial thread. (If it didn't,<br>
it would run into the same breakpoint trap. Honest.)<br>
<br>
[~] gb@antinomial> ccl<br>
Welcome to Clozure Common Lisp Version 1.6-dev-r14118M-trunk (DarwinX8632)!<br>
;;; Two lisp processes are running: the listener, and the initial<br>
;;; process. Each of these lisp processes is implemented as a<br>
;;; native OS thread.<br>
? :proc<br>
1 : -> listener [Active] 0 : Initial [Sleep] ;;; Let's try to open the CoreFoundation library from the<br>
listener<br>
;;; process.<br>
? (open-shared-library "CoreFoundation.framework/CoreFoundation")<br>
Trace/BPT trap<br>
<br>
Lots of other OSX libraries will (directly or transitively) load<br>
CoreFoundation. CoreFoundation's initialization code checks in 10.6<br>
to see if it's being called on the initial thread; if not, it executes<br>
an illegal debugging instruction and the process terminates. That's<br>
not a particulary graceful way to fail, but that's what happens.<br>
<br>
I hope that this is clear; apologies to everyone to which it was<br>
already clear.<br>
<br>
<br>
On Thu, 5 Aug 2010, <a href="mailto:k2msmith@gmail.com" target="_blank">k2msmith@gmail.com</a> wrote:<br>
<br>
Are you running this on clozure 1.5 with Snow Leopard MAC OS (ie: version<br>
10.6.4 ) ?<br>
<br>
On Aug 5, 2010 4:36am, Alexander Repenning <<a href="mailto:ralex@cs.colorado.edu" target="_blank">ralex@cs.colorado.edu</a>> wrote:<br>
> XMLisp <a href="http://code.google.com/p/xmlisp/" target="_blank">http://code.google.com/p/xmlisp/</a> works fine, i.e., it is not an<br>
OpenGL problem.<br>
><br>
><br>
> alex<br>
><br>
><br>
><br>
><br>
><br>
> On Aug 2, 2010, at 4:11 AM, Kevin Smith wrote:<br>
><br>
> further to this message.. I tried the lastest svn "trunk" release of ccl<br>
(which incidentally looks like it has some extra goodies in it for the mac<br>
platform).. Here is what I get (after startup)..<br>
><br>
><br>
> Welcome to Clozure Common Lisp Version 1.5-dev-r13523M-trunk<br>
(DarwinX8664)!<br>
> ? (require :cl-opengl)<br>
> Trace/BPT trap<br>
><br>
><br>
> All other require packages got loaded successfully on startup prior. I<br>
played around with "trace" and "step" but none of those debugging functions<br>
seem to give me the equivalent of a "stack trace' in C. Not sure how to<br>
proceed to find out where it is crashing...<br>
><br>
><br>
><br>
> Thanks,<br>
> Kevin<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Sun, Aug 1, 2010 at 6:04 PM, Kevin Smith <a href="mailto:k2msmith@gmail.com" target="_blank">k2msmith@gmail.com</a>> wrote:<br>
><br>
> The only hurdle for me for trying out (and maybe switching) to clozure on<br>
the mac platform is that I can't seem to get the cl-opengl package loaded.<br>
I get the error: "Trace/BPT trap" when I try to load that package. (All<br>
other dependent packages like cffi, loaded successfully).<br>
><br>
><br>
><br>
> I am using ccl64, version 1.5 on Darwin/MAC OS (DarwinX8664). Latest<br>
version of cl-opengl.<br>
><br>
><br>
> I believe I also tried it on the 32-bit ccl. Same problem. It looks like<br>
it only compiles a few source files in the cl-opengl package before it dies.<br>
><br>
><br>
><br>
><br>
> If someone can point out to me how I can trace this to provide more<br>
information on where it is crashing or maybe someone has run across this<br>
already with this particular package.<br>
><br>
><br>
><br>
><br>
> Thanks,<br>
> Kevin<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Openmcl-devel mailing list<br>
> <a href="mailto:Openmcl-devel@clozure.com" target="_blank">Openmcl-devel@clozure.com</a><br>
> <a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br>
><br>
><br>
><br>
> Prof. Alexander Repenning<br>
> University of ColoradoComputer Science DepartmentBoulder, CO 80309-430<br>
> vCard: <a href="http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf" target="_blank">http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div>