Log in

disable ldb at runtime in sbcl

If sbcl suffers a low-level problem and crashes, it normally enters a low-level debugger called "ldb" and waits for you to start troubleshooting. That's not so nice if you want the application to simply crash and restart automatically and unattended.

You can disable ldb by tweaking *FEATURES* at build time, but that's a little inconvenient. So here's a way to do it at runtime, inspired by a hint from David Lichteblau:

(funcall (sb-alien:define-alien-routine 
          ("disable_lossage_handler" cl-user::disable-sbcl-ldb) 

Thanks to Stas Boukarev for helping me test it.

update Pierre Mai suggested a better sb-alien technique:

    (sb-alien:extern-alien "disable_lossage_handler" (function sb-alien:void)))

He has more helpful info in his comment. And the original author of ldb in CMUCL also chipped in.



More direct version and alternatives

I think this is a good hint, and possibly more should be done to make disabling just the ldb easier out of the box. FWIW, I don't think the return value of sb-alien:define-alien-routine is actually specified, and for a one-off call d-a-r isn't actually needed or useful (creating a new throw-away function), so the shorter use of alien-funcall might be better, i.e.:
    (sb-alien:extern-alien "disable_lossage_handler" (function sb-alien:void)))
should do the same in a cleaner way. Of course as a library definition it might make more sense to do
  (sb-alien:define-alien-routine ("disable_lossage_handler" disable-sbcl-ldb)
  (sb-alien:define-alien-routine ("enable_lossage_handler" enable-sbcl-ldb)
which also makes enable-sbcl-ldb available, for re-enabling the ldb, if that is wanted. That said, you can get the same behaviour, plus a disabled lisp debugger by just calling the slightly underdocumented
which mirrors the behaviour of passing --disable-debugger to the sbcl runtime. Reenabling is via
which I think is even less documented.

Re: More direct version and alternatives

Thanks for the improved sb-alien code!

In my case, I only want the "disable ldb" aspect of --disable-debugger, so sb-ext:disable-debugger doesn't quite do what I need.
hey that's my code you are disabling! :-)

ldb was a hack that i wrote when wlott and i were bringing up cmucl under the new runtime with python.

it was never intended for anyone but language developers. it is kind of stupid for it to be invoked by default in any normal situation.
Here's the bit from the SBCL customization file:

 ;; Build SBCL with the old CMU CL low level debugger, "ldb". In the
 ;; ideal world you would not need this unless you are messing with
 ;; SBCL at a very low level (e.g., trying to diagnose GC problems, or
 ;; trying to debug assembly code for a port to a new CPU). However,
 ;; experience shows that sooner or later everyone lose()'s, in which
 ;; case SB-LDB can at least provide an informative backtrace.
they got the original reasons for ldb right. (i wrote the gc and helped write a couple of the compiler backends.) i'm pleased to read that it is still of some use. it was half intended to be a throwaway.

but i still maintain that a decent dump that would be useful for debugging bigtime lossage could be produced (perhaps even by ldb) without ever dropping the average luser into the ldb command loop.

SBCL, at least the version shipped with FC9 drops into LDB when . is unavailable (due to, for example, NFS problems). Perhaps I should file a bug report with the Responsible Persons, but running across this entry, I figured someone else might get some amusement out of it.