From: Daniel W. <dl...@it...> - 2010-06-17 17:33:12
|
If you run SBCL with --disable-debugger, the documentation says: |--disable-debugger| By default when SBCL encounters an error, it enters the builtin debugger, allowing interactive diagnosis and possible intercession. This option disables the debugger, causing errors to print a backtrace and exit with status 1 instead. When given, this option takes effect before loading of initialization files or processing |--eval| and |--load| options. See |sb-ext:disable-debugger| for details. See Debugger Entry <http://www.sbcl.org/manual/Debugger-Entry.html#Debugger-Entry>. However, when there is an unhandled error in a thread other than the initial thread, SBCL does not exit. Is this intentional? I notice that make-thread does not use handling-end-of-the-world, and if it did, then I think SBCL would exit in that case. Thanks. -- Dan |
From: Tobias C R. <tc...@fr...> - 2010-06-18 04:52:37
|
In article <4C1...@it...>, Daniel Weinreb <dl...@it...> wrote: > If you run SBCL with --disable-debugger, the documentation says: > > |--disable-debugger| > By default when SBCL encounters an error, it enters the builtin > debugger, allowing interactive diagnosis and possible intercession. > This option disables the debugger, causing errors to print a > backtrace and exit with status 1 instead. When given, this option > takes effect before loading of initialization files or processing > |--eval| and |--load| options. See |sb-ext:disable-debugger| for > details. See Debugger Entry > <http://www.sbcl.org/manual/Debugger-Entry.html#Debugger-Entry>. > > However, when there is an unhandled error in a thread other > than the initial thread, SBCL does not exit. > > Is this intentional? > > I notice that make-thread does not use handling-end-of-the-world, > and if it did, then I think SBCL would exit in that case. > > Thanks. Unhandled errors in different thread than the main thread are in general bad shape. It does not seem to be possible to use the debugger interactively in that case, so you can't even get a backtrace. In Slime, the problem manifests itself, too, in that "B" in the Slime debugger is useless on SBCL -- it's supposed to break into the implementation's native debugger. Iirc, ECL implement this case by suspending all running threads, hijacking the main thread, and waiting for user input there. -T. |
From: Helmut E. <he...@co...> - 2010-06-18 05:56:04
|
* Tobias C Rittweiler [2010-06-18 06:52+0200] writes: > In Slime, the problem manifests itself, too, in that "B" in the > Slime debugger is useless on SBCL -- it's supposed to break into > the implementation's native debugger. Well, usually the debugger waits for the lock on the terminal and you have to use sb-thread:release-foreground. It's the same in CCL just that CCL is more friendly and prints a message that the background thread needs the terminal. Helmut |