From: James Y Knight <foom@fu...> - 2006-07-18 00:39:51
The check for *invoke-debugger-hook* being nil in disable-debugger is
causing a minor problem for me, as I'd like to start my saved core
with --disable-debugger, sometimes. But I have overridden invoke-
debugger-hook as follows, to work around another issue I ran into:
> ;;; Patch up the debugger so that it doesn't run serve-events
> ;;; Running app code asynchronously while you're trying to debug it
> ;;; is *NOT* helpful.
> (defvar *old-descriptor-handlers* nil) ; for inspecting in debugger
> (defun invoke-debugger-without-event-callbacks (condition &optional
> (declare (ignore val))
> (let ((*old-descriptor-handlers* sb-impl::*descriptor-handlers*)
> (sb-impl::*descriptor-handlers* ()))
> (invoke-debugger condition)))
> (setf sb-impl::*invoke-debugger-hook* #'invoke-debugger-without-
The --disable-debugger command-line option thus doesn't do anything,
since invoke-debugger-hook has already been set at core-load-time.
Of course, I can work around the disable-debugger problem easily enough:
> (defun sb-debug::disable-debugger ()
> ;; override sbcl's disable-debugger so that it unconditionally
> disables the debugger.
> (setf sb-impl::*invoke-debugger-hook* 'sb-debug::debugger-
> (sb-alien:alien-funcall (sb-alien:extern-alien
> "disable_lossage_handler" (function sb-alien:void)))))
But perhaps one or both of these issues can be fixed in sbcl rather
than layering hack upon hack in my code. :)
From: Juho Snellman <jsnell@ik...> - 2006-08-04 14:30:44
James Y Knight <foom@...> writes:
> The check for *invoke-debugger-hook* being nil in disable-debugger is
> causing a minor problem for me, as I'd like to start my saved core
> with --disable-debugger, sometimes.
As of 0.9.15.9 the NIL check has been replaced with storing the old
value of the hook when disabling the debugger, and restoring it when
the debugger is enabled again.