[slime-devel] Allegro 6.2 problem
This may be related to the thing Edi mentioned the other day. Anyway, I start SLIME using Allegro 6.2 on Linux. Initially I'm in the directory where test-debug.lisp lives: ; SLIME: The Superior Lisp Interaction Mode for Emacs CL-USER> CL-USER> (compile-file "test-debug.lisp") ;;; Compiling file test-debug.lisp ;;; Writing fasl file test-debug.fasl ;;; Fasl write complete #p"test-debug.fasl" NIL NIL So far so good. Now I ,change-directory up one directory and try again. Which should fail since the file won't be found. But it doesn't just fail; in the SLIME repl window I get the following: CL-USER> CL-USER> (compile-file "test-debug.lisp") Error: Received signal number 11 (Segmentation violation) [condition type: SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL] Restart actions (select using :continue): 0: Prompt for a different filename to compile 1: Abort handling SLIME request. 2: Abort entirely from this process. [Current process: repl-thread] [1] CL-USER(1): Typing Allegro commands (e.g. :cont 1) doesn't seem to do anything. C-c C-c gets me into sldb where I can use one of the ABORT restarts to get back to the main REPL. But this seems wrong. -Peter -- Peter Seibel peter@javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <peter@javamonkey.com> writes:
CL-USER> (compile-file "test-debug.lisp") Error: Received signal number 11 (Segmentation violation) [condition type: SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL]
Restart actions (select using :continue): 0: Prompt for a different filename to compile 1: Abort handling SLIME request. 2: Abort entirely from this process. [Current process: repl-thread] [1] CL-USER(1):
Typing Allegro commands (e.g. :cont 1) doesn't seem to do anything. C-c C-c gets me into sldb where I can use one of the ABORT restarts to get back to the main REPL. But this seems wrong.
I find it troubling that so many simple errors like this cause SIGSEGV in ACL, but that's another story. Can you try again from CVS? From the ChangeLog I think that Brian Downing has probably fixed this. Another issue is that it hits the TTY debugger instead of SLDB. Perhaps Franz have a different *debugger-hook*'alike for (some) signals? If so we might want to optionally SLDB'ify it. P.S., Franz have come through with a couple of ACL licenses for us, and Kevin Layer of Franz has also looked over swank-allegro.lisp and offered to answer questions. (Thanks!) -Luke
Luke Gorrie <luke@bluetail.com> writes:
Another issue is that it hits the TTY debugger instead of SLDB. Perhaps Franz have a different *debugger-hook*'alike for (some) signals? If so we might want to optionally SLDB'ify it.
Yes, Allegro has a *break-hook*. I figure it's time for a call-with-sldb-hook backend function. That's going to me messy :-) Helmut.
Luke Gorrie <luke@bluetail.com> writes:
Peter Seibel <peter@javamonkey.com> writes:
CL-USER> (compile-file "test-debug.lisp") Error: Received signal number 11 (Segmentation violation) [condition type: SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL]
Restart actions (select using :continue): 0: Prompt for a different filename to compile 1: Abort handling SLIME request. 2: Abort entirely from this process. [Current process: repl-thread] [1] CL-USER(1):
Typing Allegro commands (e.g. :cont 1) doesn't seem to do anything. C-c C-c gets me into sldb where I can use one of the ABORT restarts to get back to the main REPL. But this seems wrong.
I find it troubling that so many simple errors like this cause SIGSEGV in ACL, but that's another story.
Can you try again from CVS? From the ChangeLog I think that Brian Downing has probably fixed this.
Nope. His fix fixed my other problem (with the interactive restart) but not this one. -Peter -- Peter Seibel peter@javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <peter@javamonkey.com> writes:
Luke Gorrie <luke@bluetail.com> writes:
Peter Seibel <peter@javamonkey.com> writes:
CL-USER> (compile-file "test-debug.lisp") Error: Received signal number 11 (Segmentation violation) [condition type: SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL]
Restart actions (select using :continue): 0: Prompt for a different filename to compile 1: Abort handling SLIME request. 2: Abort entirely from this process. [Current process: repl-thread] [1] CL-USER(1):
Typing Allegro commands (e.g. :cont 1) doesn't seem to do anything. C-c C-c gets me into sldb where I can use one of the ABORT restarts to get back to the main REPL. But this seems wrong.
I find it troubling that so many simple errors like this cause SIGSEGV in ACL, but that's another story.
Can you try again from CVS? From the ChangeLog I think that Brian Downing has probably fixed this.
Nope. His fix fixed my other problem (with the interactive restart) but not this one.
Er, I hadn't realised that the segfaults were our fault :-) The segfault is triggered in SLDB when we call `debug:output-frame' to format a particular stack frame for the backtrace. I don't know what's special about this frame, but poking around in the TTY debugger I noticed that `debug:frame-visible-p' returns NIL for it. So, as a pretty lame workaround, I changed the backtrace to filter out all frames that aren't visible-p. Don't know if this really solved the problem, so please give a shout if there are any more of these segfaults. -Luke
Luke Gorrie <luke@bluetail.com> writes:
Peter Seibel <peter@javamonkey.com> writes:
Luke Gorrie <luke@bluetail.com> writes:
Peter Seibel <peter@javamonkey.com> writes:
CL-USER> (compile-file "test-debug.lisp") Error: Received signal number 11 (Segmentation violation) [condition type: SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL]
Restart actions (select using :continue): 0: Prompt for a different filename to compile 1: Abort handling SLIME request. 2: Abort entirely from this process. [Current process: repl-thread] [1] CL-USER(1):
Typing Allegro commands (e.g. :cont 1) doesn't seem to do anything. C-c C-c gets me into sldb where I can use one of the ABORT restarts to get back to the main REPL. But this seems wrong.
I find it troubling that so many simple errors like this cause SIGSEGV in ACL, but that's another story.
Can you try again from CVS? From the ChangeLog I think that Brian Downing has probably fixed this.
Nope. His fix fixed my other problem (with the interactive restart) but not this one.
Er, I hadn't realised that the segfaults were our fault :-)
Heh.
The segfault is triggered in SLDB when we call `debug:output-frame' to format a particular stack frame for the backtrace. I don't know what's special about this frame, but poking around in the TTY debugger I noticed that `debug:frame-visible-p' returns NIL for it. So, as a pretty lame workaround, I changed the backtrace to filter out all frames that aren't visible-p.
Don't know if this really solved the problem, so please give a shout if there are any more of these segfaults.
Well it seems to have worked--now I end up in SLDB with an error about the file not existing which is what I'd expect. Cool. -Peter -- Peter Seibel peter@javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp
participants (3)
-
Helmut Eller -
Luke Gorrie -
Peter Seibel