From: Christophe R. <cs...@ca...> - 2005-05-11 19:18:40
|
Hi, I should preface this mail by saying that I have emphatically not turned into a Great Hacker by Paul Graham's standards (which means I'm _really_ in the dark about the technical bits of this). Nevertheless, for several reasons, it has become necessary for me to do some lisp work on Macs... and I have run into a somewhat peculiar problem, which Brian M and Nikodemus have helped to isolate and partially diagnose. --- begin frob.c --- /* gcc -framework CoreMIDI -framework AudioToolbox -framework CoreAudio \ -framework Carbon -framework AudioUnit -dynamiclib -o frob.so frob.c (load-shared-object "frob.so") (define-alien-routine frob int) */ #include <AudioToolbox/AudioToolbox.h> #include <CoreMIDI/CoreMIDI.h> int frob () { AUGraph graph; AUGraphOpen(graph); return 1; } --- end frob.c --- Consider the above file as frob.c in the current working directory. Perform the compilation as in the first portion of the comment, and then run "sbcl". Execute the remaining two lines: everything should work as expected. Now, exit from that sbcl, and run "sbcl --core /usr/lib/sbcl/sbcl.core" (or whatever your path to sbcl.core is). Re-execute the two lisp lines. I would be very interested in success/failure reports for this, because at least for me, it would appear that the presence of --core on the sbcl command line causes the DEFINE-ALIEN-ROUTINE to signal an EXC_BAD_ACCESS (or SIGBUS, to us Unix types). And I have no idea why. I'll hear any ideas, Cheers, Christophe |
From: Raffael C. <raf...@ma...> - 2005-05-11 19:58:05
|
On May 11, 2005, at 3:15 PM, Christophe Rhodes wrote: > I would be very interested in success/failure reports for this, > because at least for me, it would appear that the presence of --core > on the sbcl command line causes the DEFINE-ALIEN-ROUTINE to signal an > EXC_BAD_ACCESS (or SIGBUS, to us Unix types). raffaelc$ sbcl --core /usr/lib/sbcl/sbcl.core This is SBCL 0.9.0, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (load-shared-object "frob.so") debugger invoked on a SIMPLE-ERROR in thread 18150: bus error at #X90124960 Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-UNIX::SIGBUS-HANDLER #<unavailable argument> #<unavailable argument> #.(SB-SYS:INT-SAP #XBFFFDD50)) 0] It doesn't even take the (define-alien-routine frob int) to do it - just loading the .so does it. I have no idea why, though I can confirm your results on a dual G5 2.0GHz under 10.4.x. regards Raffael Cavallaro, Ph.D. raf...@ma... |
From: Raymond W. <Ray...@fa...> - 2005-05-12 04:47:56
|
Raffael Cavallaro writes: > debugger invoked on a SIMPLE-ERROR in thread 18150: bus error at > #X90124960 > > Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [ABORT] Exit debugger, returning to top level. > > (SB-UNIX::SIGBUS-HANDLER > #<unavailable argument> > #<unavailable argument> > #.(SB-SYS:INT-SAP #XBFFFDD50)) > 0] > > It doesn't even take the (define-alien-routine frob int) to do it - > just loading the .so does it. I have no idea why, though I can > confirm your results on a dual G5 2.0GHz under 10.4.x. Same behaviour with SBCL 9.0.27, also on a dual G5 2.0GHz under 10.4. |
From: Cyrus H. <ch...@bo...> - 2005-05-12 05:13:21
|
Interestingly, if you do this in slime and abort, subsequent calls to (load-shared-library work fine. On May 11, 2005, at 9:47 PM, Raymond Wiker wrote: > Raffael Cavallaro writes: > >> debugger invoked on a SIMPLE-ERROR in thread 18150: bus error at >> #X90124960 >> >> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. >> >> restarts (invokable by number or by possibly-abbreviated name): >> 0: [ABORT] Exit debugger, returning to top level. >> >> (SB-UNIX::SIGBUS-HANDLER >> #<unavailable argument> >> #<unavailable argument> >> #.(SB-SYS:INT-SAP #XBFFFDD50)) >> 0] >> >> It doesn't even take the (define-alien-routine frob int) to do it - >> just loading the .so does it. I have no idea why, though I can >> confirm your results on a dual G5 2.0GHz under 10.4.x. >> > > Same behaviour with SBCL 9.0.27, also on a dual G5 2.0GHz > under 10.4. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Christophe R. <cs...@ca...> - 2005-05-12 08:10:07
|
Cyrus Harmon <ch...@bo...> writes: > Interestingly, if you do this in slime and abort, subsequent calls to > (load-shared-library work fine. This is true, but in my experience the calls into the foreign library do not. In my specific instance, the symptom is that AUOpenGraph hangs eternally while apparently waiting on a semaphore in FindComponent(). Cheers, Christophe |
From: Michael H. <mw...@py...> - 2005-05-12 07:33:12
|
Christophe Rhodes <cs...@ca...> writes: > #include <AudioToolbox/AudioToolbox.h> > #include <CoreMIDI/CoreMIDI.h> > > int frob () { > AUGraph graph; > > AUGraphOpen(graph); > > return 1; > } > --- end frob.c --- > > Consider the above file as frob.c in the current working directory. > Perform the compilation as in the first portion of the comment, and > then run "sbcl". Execute the remaining two lines: everything should > work as expected. > > Now, exit from that sbcl, and run "sbcl --core > /usr/lib/sbcl/sbcl.core" (or whatever your path to sbcl.core is). > Re-execute the two lisp lines. The only thing that springs to mind is, does CoreAudio depends on a connection to the window manager? It's possible something deep in the bowels is expecting a -psn_XXXX style argument and messing up when it fails to find one. Seems a bit unlikely, though. Cheers, mwh -- What the semicolon's anxious supporters fret about is the tendency of contemporary writers to use a dash instead of a semicolon and thus precipitate the end of the world. -- Lynne Truss, "Eats, Shoots & Leaves" |
From: Christophe R. <cs...@ca...> - 2005-05-12 08:12:53
|
Michael Hudson <mw...@py...> writes: > The only thing that springs to mind is, does CoreAudio depends on a > connection to the window manager? It's possible something deep in the > bowels is expecting a -psn_XXXX style argument and messing up when it > fails to find one. Seems a bit unlikely, though. Apparently not. A slightly more complete CoreMIDI/CoreAudio program is able to play midi beeps from C over an ssh connection; and indeed my CoreMIDI Lisp bindings are able to do likewise if --core is not provided on the command line... Um. It's not possible that "--core" itself could be the culprit, is it? You say something about command-lines... Cheers, Christophe |
From: Christophe R. <cs...@ca...> - 2005-05-12 09:54:06
|
Christophe Rhodes <cs...@ca...> writes: > Um. It's not possible that "--core" itself could be the culprit, is > it? You say something about command-lines... Replying to myself: an SBCL modified to use --c rather than --core shows the same symptoms. So no, --core itself is unlikely to be the culprit. However, arranging for sbcl.core to be in the appropriate place, and then running sbcl with $ SBCL_HOME=`pwd`/contrib ./src/runtime/sbcl --frob output/sbcl.core (where --frob is meaningless) gives an sbcl which does not suffer the SIGBUS. This would tend to imply that it's the --core argument handling itself which causes the problem... Cheers, Christophe |
From: Michael H. <mw...@py...> - 2005-05-12 09:22:07
|
Christophe Rhodes <cs...@ca...> writes: > Michael Hudson <mw...@py...> writes: > >> The only thing that springs to mind is, does CoreAudio depends on a >> connection to the window manager? It's possible something deep in the >> bowels is expecting a -psn_XXXX style argument and messing up when it >> fails to find one. Seems a bit unlikely, though. > > Apparently not. A slightly more complete CoreMIDI/CoreAudio program > is able to play midi beeps from C over an ssh connection; and indeed > my CoreMIDI Lisp bindings are able to do likewise if --core is not > provided on the command line... > > Um. It's not possible that "--core" itself could be the culprit, is > it? You say something about command-lines... Well, unless I misread your initial email (truth in advertising: I didn't try the listed steps) the difference between the working situation and the non-working situation is the command line, no? Given this, the fact that Mac OS X passes an inscrutable command line argument when you double click applications in the finder (well, open them through Launch Services, really) bubbled to the top of my mind. It's very much a guess, though. Cheers, mwh -- incidentally, asking why things are "left out of the language" is a good sign that the asker is fairly clueless. -- Erik Naggum, comp.lang.lisp |
From: Christophe R. <cs...@ca...> - 2005-05-12 11:51:41
|
Christophe Rhodes <cs...@ca...> writes: > and I have run into a somewhat peculiar problem, which Brian M and > Nikodemus have helped to isolate and partially diagnose. With a bit more help from Michael Hudson, I think I understand what's happening. SBCL mutates argc and argv, removing runtime options such as --noinform and --core foo from the argument list as seen by higher levels. It's possible we even do so conformingly, as C99 says The parameters argc and argv and the strings pointed to by the argv array shall be modifiable by the program, and retain their last-stored values between program startup and program termination. So, if sbcl starts up with the command line sbcl --noinform --noinform the initial argc and argv are argc = 3; argv[0] = "/possibly/path/to/sbcl" argv[1] = "--noinform" argv[2] = "--noinform" and we alter that to argc = 1; argv[0] = "/possibly/path/to/sbcl" argv[1] = NULL. This hasn't caused us problems in the past. However, when an Apple Framework is initialized, it would appear to scan argv[] for arguments named -AppleLanguage; it does so based on the original value of argc, not the altered one, and therefore trips up on the now-NULL argv[1]. To work around this, we'll probably have to preserve the original argc and argv[], and propagate a new argv[] to the Lisp-side argument processing. This fix will almost certainly feature in sbcl-0.9.1 *Sheesh*. Cheers, Christophe |