[slime-devel] invoke-nth-restart, cmucl and *communication-style* :sigio
connecting to a remote (as in slime-connect) cmucl lisp with the *communication-style* set to :sigio. a thread signals an error and i get an sldb debugger in emacs. however none of the restarts actually do anything. all i get is a message in the minibuffer "Restart returned: nil" and i'm left in the debugger. the only restart which causes a noticable change is the sldb-abort restart, which gets me out of the debugger but leave the thread waiting for input. setting the *communication-style* to :spawn fixs the issue. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
in attempting to show how to reproduce this bug i came across another interesting piece of info. if you do: segv@6[examples]$ lisp ; Loading #p"/opt/home/segv/.cmucl-init.lisp". CMU Common Lisp CVS release-18e-branch + minimal debian patches, running on merlin With core: /usr/lib/cmucl/lisp.core Dumped on: Sun, 2004-07-04 03:12:00-07:00 on merlin For support see http://www.cons.org/cmucl/support.html Send bug reports to the debian BTS. or to pvaneynd@debian.org type (help) for help, (quit) to exit, and (demo) to see the demos Loaded subsystems: Python 1.1, target Intel x86 CLOS 18e (based on PCL September 16 92 PCL (f)) * (asdf:oos 'asdf:load-op :swank) * (setf *debugger-hook* #'swank:swank-debugger-hook) * (swank:create-swank-server) ;;; now go and connect emacs to this lisp * (with-simple-restart (test "Can't call me.") (swank::spawn (lambda () (error "ERR")))) notice how the sldb buffer doesn't show the test restart. does *sldb-restarts* need some special handling when using :SIGIO? -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Marco Baringer <mb@bese.it> writes:
connecting to a remote (as in slime-connect) cmucl lisp with the *communication-style* set to :sigio. a thread signals an error and i get an sldb debugger in emacs. however none of the restarts actually do anything.
Thanks, I've reproduced. The Lisp doesn't have to be remote. I'll check this out tonight. Debugging our thread support on CMUCL and LispWorks is currently on top of my todo list. And from the other mail:
;;; now go and connect emacs to this lisp * (with-simple-restart (test "Can't call me.") (swank::spawn (lambda () (error "ERR"))))
notice how the sldb buffer doesn't show the test restart. does *sldb-restarts* need some special handling when using :SIGIO?
This looks correct to me. The restart exists on the stack of the parent thread and not the thread that's hitting the debugger. To see the restart you'd need to do: (swank::spawn (lambda () (with-simple-restart (test "Can't call me.") (error "ERR")))) In this case we do see the restart in SLDB but get the other problem of being unable to invoke it (in :sigio at least). -Luke
Luke Gorrie <luke@bluetail.com> writes:
This looks correct to me.
yeah, brain fart. you know when you spend all morning debugging and after a while _everything_ starts looking like a bug? :) -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Marco Baringer <mb@bese.it> writes:
connecting to a remote (as in slime-connect) cmucl lisp with the *communication-style* set to :sigio. a thread signals an error and i get an sldb debugger in emacs. however none of the restarts actually do anything.
The gist is that to deal with multiple threads it's necessary to use the :spawn communication style. Swank uses some threads of its own to coordinate the other activities, but only in :spawn mode. -Luke
participants (2)
-
Luke Gorrie -
Marco Baringer