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.
Get latest updates about Open Source Projects, Conferences and News.