[Openmcl-devel] Trace/BPT trap with cl-opengl loading
Kevin Smith
k2msmith at gmail.com
Sat Aug 7 12:43:23 PDT 2010
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.
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.
On Sat, Aug 7, 2010 at 12:40 AM, Gary Byers <gb at clozure.com> wrote:
>
>
> On Fri, 6 Aug 2010, Kevin Smith wrote:
>
> 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
>> the same code (same cffi and cl-opengl packages), including my opencv
>> libraries. I've not investigated what sbcl (or cffi)
>> maybe doing that is different in this case, but it all seems to be
>> working.
>>
>
> As I'm getting tired of saying and other people are likely tired of
> hearing - the bkpt trap happens when the CoreFoundation library is
> initialized on some thread other than the initial one. In CCL, the
> thread in which the REPL runs is not the initial thread; I assume that
> it is when SBCL's run from the shell. Depending on how SLIME's set up,
> a multithreaded SBCL running under SLIME will run SLIME's REPL on some
> non-initial thread. (Someone who's interested in and familiar with
> SBCL and SLIME can probably explain how to set things up if it doesn't
> work like this out of the box.) I assume that many people who run SBCL
> under SLIME run it this way (with SLIME's REPL running in its own thread);
> if you execute code that tries to open the CoreFoundation library in that
> thread, what would you expect to happen ?
>
> The source to a small C program is enclosed; it creates a thread and that
> thread tries to open CoreFoundation. If you compile that little program
> and run it (comments near the start of the file explain how), what do you
> think will happen ?
>
> I recognize that this is a little obscure and a little subtle. I have
> a lot of difficulty believing that it's -this- obscure or -this- subtle,
> and I really hope that the experiments (running the little C program,
> running SBCL in a SLIME REPL thread) will make this issue both crystal
> clear and completely uninteresting for you.
>
> I said earlier that CCL could help to keep people from running into
> this problem by making OPEN-SHARED-LIBRARY transparently open the
> library from the initial thread by default. I checked that change into
> the trunk a few minutes ago; I hope that it'll keep people from running
> into the problem and especially hope that it'll prevent them from
> thinking that it's interesting in some way.
>
>
>
>
>> On Thu, Aug 5, 2010 at 8:20 AM, Gary Byers <gb at clozure.com> wrote:
>> The "trace/bkpt trap" happens - as you've already confirmed - when
>> a thread other than the initial thread tries to open/initialize
>> a particular shared library. (I'm fairly sure that the library
>> in question is CoreFoundation, which is used by many other things
>> on OSX.)
>>
>> Alex's XMLisp stuff runs on top of CCL's Cocoa environment, which
>> takes great care to ensure that the Cocoa framework (and therefore
>> CoreFoundation) are loaded on the initial thread. (If it didn't,
>> it would run into the same breakpoint trap. Honest.)
>>
>> [~] gb at antinomial> ccl
>> Welcome to Clozure Common Lisp Version 1.6-dev-r14118M-trunk
>> (DarwinX8632)!
>> ;;; Two lisp processes are running: the listener, and the initial
>> ;;; process. Each of these lisp processes is implemented as a
>> ;;; native OS thread.
>> ? :proc
>> 1 : -> listener [Active] 0 : Initial [Sleep] ;;; Let's
>> try to open the CoreFoundation library from the
>> listener
>> ;;; process.
>> ? (open-shared-library "CoreFoundation.framework/CoreFoundation")
>> Trace/BPT trap
>>
>> Lots of other OSX libraries will (directly or transitively) load
>> CoreFoundation. CoreFoundation's initialization code checks in 10.6
>> to see if it's being called on the initial thread; if not, it
>> executes
>> an illegal debugging instruction and the process terminates. That's
>> not a particulary graceful way to fail, but that's what happens.
>>
>> I hope that this is clear; apologies to everyone to which it was
>> already clear.
>>
>>
>> On Thu, 5 Aug 2010, k2msmith at gmail.com wrote:
>>
>> Are you running this on clozure 1.5 with Snow Leopard MAC OS (ie:
>> version
>> 10.6.4 ) ?
>>
>> On Aug 5, 2010 4:36am, Alexander Repenning <ralex at cs.colorado.edu>
>> wrote:
>> > XMLisp http://code.google.com/p/xmlisp/ works fine, i.e., it is
>> not an
>> OpenGL problem.
>> >
>> >
>> > alex
>> >
>> >
>> >
>> >
>> >
>> > On Aug 2, 2010, at 4:11 AM, Kevin Smith wrote:
>> >
>> > further to this message.. I tried the lastest svn "trunk" release
>> of ccl
>> (which incidentally looks like it has some extra goodies in it for
>> the mac
>> platform).. Here is what I get (after startup)..
>> >
>> >
>> > Welcome to Clozure Common Lisp Version 1.5-dev-r13523M-trunk
>> (DarwinX8664)!
>> > ? (require :cl-opengl)
>> > Trace/BPT trap
>> >
>> >
>> > All other require packages got loaded successfully on startup
>> prior. I
>> played around with "trace" and "step" but none of those debugging
>> functions
>> seem to give me the equivalent of a "stack trace' in C. Not sure how
>> to
>> proceed to find out where it is crashing...
>> >
>> >
>> >
>> > Thanks,
>> > Kevin
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Sun, Aug 1, 2010 at 6:04 PM, Kevin Smith k2msmith at gmail.com>
>> 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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Openmcl-devel mailing list
>> > Openmcl-devel at clozure.com
>> > http://clozure.com/mailman/listinfo/openmcl-devel
>> >
>> >
>> >
>> > Prof. Alexander Repenning
>> > University of ColoradoComputer Science DepartmentBoulder, CO
>> 80309-430
>> > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100807/f4f418e0/attachment.htm>
More information about the Openmcl-devel
mailing list