[Openmcl-devel] Trace/BPT trap with cl-opengl loading
Gary Byers
gb at clozure.com
Sat Aug 7 00:40:03 PDT 2010
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 --------------
/*
Oh my god! C has the same bug as CCL!
$ cc -o bug bug.c
$ ./bug
*/
#include <pthread.h>
#include <dlfcn.h>
void *
thread_function(void *arg)
{
return dlopen("CoreFoundation.framework/CoreFoundation",RTLD_NOW);
}
main()
{
pthread_t thread;
pthread_attr_t attr;
void *val;
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_JOINABLE);
pthread_create(&thread, &attr, thread_function, NULL);
pthread_join(thread, &val);
}
More information about the Openmcl-devel
mailing list