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 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 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
-
Helmut Eller -
Luke Gorrie -
Peter Seibel