Re: [j-devel] errors are ignored

[Andras Simon <asimon@ma...>]

On Fri, 23 Feb 2007, Peter Graves wrote:


> There may still be other issues because of the signal-related changes,
> but running ansi-tests doesn't reveal them.

Here's one that running ansi-tests is unlikely to reveal... on the
other hand, it may not be due to the signal-related changes (I'm
not even sure it's a regression).

Armed Bear Common Lisp 0.0.9.1+ (built Sat Feb 24 2007 01:38:21 --100)
Java 1.5.0_08 Sun Microsystems Inc.
Java HotSpot(TM) Client VM 
Control-C handler installed.
Low-level initialization completed in 9.142 seconds. 
Startup completed in 26.542 seconds.
Type ":help" for a list of available commands. 
CL-USER(1): (loop) ;; here I try Ctrl-C, but nothing happens. then
                    ;; another Ctrl-C gives this:
Error loading
/home/simon/java/j2/j/src/org/armedbear/lisp/with-standard-io-syntax.abcl
at line 3 (offset 52)
Debugger invoked on condition of type SIMPLE-CONDITION:
   BREAK called
Restarts:
   0: CONTINUE  Return from BREAK.
   1: CONTINUE  Return from BREAK.
   2: TOP-LEVEL Return to top level.
[1] CL-USER(2): 2
;; No prompt, but according to top, java is very active.
;; Ctrl-C again
Error loading
/home/simon/java/j2/j/src/org/armedbear/lisp/with-standard-io-syntax.abcl
at line 3 (offset 52)
Debugger invoked on condition of type SIMPLE-CONDITION:
   BREAK called
Restarts:
   0: ABORT     Return to debug level 1.
   1: CONTINUE  Return from BREAK.
   2: CONTINUE  Return from BREAK.
   3: CONTINUE  Return from BREAK.
   4: TOP-LEVEL Return to top level.
[2] CL-USER(3): 0
CL-USER(4): :ex ;;abcl hangs, top shows java activity

Andras

[j-devel] errors are ignored

[Andras Simon <asimon@ma...>]

Probably a side effect of the recent fix to signal.lisp:

Armed Bear Common Lisp 0.0.9.1+ (built Fri Feb 23 2007 17:04:27 --100) 
Java 1.5.0_08 Sun Microsystems Inc.
Java HotSpot(TM) Client VM 
Control-C handler installed.
Low-level initialization completed in 10.584 seconds. 
Startup completed in 27.255 seconds.
Type ":help" for a list of available commands. 
CL-USER(1): (/ 1 0)
NIL 
CL-USER(2):

Andras

Re: [j-devel] errors are ignored

[Peter Graves <peter@ar...>]

On Fri, 23 Feb 2007 at 18:10:37 +0100, Andras Simon wrote:
> Probably a side effect of the recent fix to signal.lisp:
>
> Armed Bear Common Lisp 0.0.9.1+ (built Fri Feb 23 2007 17:04:27 --100) 
> Java 1.5.0_08 Sun Microsystems Inc.
> Java HotSpot(TM) Client VM 
> Control-C handler installed.
> Low-level initialization completed in 10.584 seconds. 
> Startup completed in 27.255 seconds.
> Type ":help" for a list of available commands. 
> CL-USER(1): (/ 1 0)
> NIL 
> CL-USER(2):

Yeah. I was afraid of something like that, but oddly enough nothing
showed up on ansi-tests.

I'll try to get things cleaned up later today.

Sorry for the inconvenience!

-Peter

Re: [j-devel] errors are ignored

[Peter Graves <peter@ar...>]

On Fri, 23 Feb 2007 at 18:10:37 +0100, Andras Simon wrote:
> Probably a side effect of the recent fix to signal.lisp:
>
> Armed Bear Common Lisp 0.0.9.1+ (built Fri Feb 23 2007 17:04:27 --100) 
> Java 1.5.0_08 Sun Microsystems Inc.
> Java HotSpot(TM) Client VM 
> Control-C handler installed.
> Low-level initialization completed in 10.584 seconds. 
> Startup completed in 27.255 seconds.
> Type ":help" for a list of available commands. 
> CL-USER(1): (/ 1 0)
> NIL 
> CL-USER(2):

Now fixed in CVS:

    Armed Bear Common Lisp 0.0.9.1+ (built Fri Feb 23 2007 12:54:08 -0800)
    Java 1.5.0_07 Sun Microsystems Inc.
    Java HotSpot(TM) 64-Bit Server VM
    Control-C handler installed.
    Low-level initialization completed in 1.108 seconds.
    Startup completed in 3.151 seconds.
    Swank server started on port 33651.
    Type ":help" for a list of available commands.
    CL-USER(1): (/ 1 0)
    Debugger invoked on condition of type DIVISION-BY-ZERO:
      Arithmetic error DIVISION-BY-ZERO signalled.
    Restarts:
      0: TOP-LEVEL Return to top level.
    [1] CL-USER(2): 

There may still be other issues because of the signal-related changes,
but running ansi-tests doesn't reveal them.

Thanks for pointing out this problem!

-Peter

Re: [j-devel] errors are ignored

[Andras Simon <asimon@ma...>]

On Fri, 23 Feb 2007, Peter Graves wrote:

> On Fri, 23 Feb 2007 at 18:10:37 +0100, Andras Simon wrote:
>> Probably a side effect of the recent fix to signal.lisp:
>>
>> Armed Bear Common Lisp 0.0.9.1+ (built Fri Feb 23 2007 17:04:27 --100)
>> Java 1.5.0_08 Sun Microsystems Inc.
>> Java HotSpot(TM) Client VM
>> Control-C handler installed.
>> Low-level initialization completed in 10.584 seconds.
>> Startup completed in 27.255 seconds.
>> Type ":help" for a list of available commands.
>> CL-USER(1): (/ 1 0)
>> NIL
>> CL-USER(2):
>
> Now fixed in CVS:

Thanks!

Andras

Re: [j-devel] errors are ignored

[Andras Simon <asimon@ma...>]

On Fri, 23 Feb 2007, Peter Graves wrote:


> There may still be other issues because of the signal-related changes,
> but running ansi-tests doesn't reveal them.

Here's one that running ansi-tests is unlikely to reveal... on the
other hand, it may not be due to the signal-related changes (I'm
not even sure it's a regression).

Armed Bear Common Lisp 0.0.9.1+ (built Sat Feb 24 2007 01:38:21 --100)
Java 1.5.0_08 Sun Microsystems Inc.
Java HotSpot(TM) Client VM 
Control-C handler installed.
Low-level initialization completed in 9.142 seconds. 
Startup completed in 26.542 seconds.
Type ":help" for a list of available commands. 
CL-USER(1): (loop) ;; here I try Ctrl-C, but nothing happens. then
                    ;; another Ctrl-C gives this:
Error loading
/home/simon/java/j2/j/src/org/armedbear/lisp/with-standard-io-syntax.abcl
at line 3 (offset 52)
Debugger invoked on condition of type SIMPLE-CONDITION:
   BREAK called
Restarts:
   0: CONTINUE  Return from BREAK.
   1: CONTINUE  Return from BREAK.
   2: TOP-LEVEL Return to top level.
[1] CL-USER(2): 2
;; No prompt, but according to top, java is very active.
;; Ctrl-C again
Error loading
/home/simon/java/j2/j/src/org/armedbear/lisp/with-standard-io-syntax.abcl
at line 3 (offset 52)
Debugger invoked on condition of type SIMPLE-CONDITION:
   BREAK called
Restarts:
   0: ABORT     Return to debug level 1.
   1: CONTINUE  Return from BREAK.
   2: CONTINUE  Return from BREAK.
   3: CONTINUE  Return from BREAK.
   4: TOP-LEVEL Return to top level.
[2] CL-USER(3): 0
CL-USER(4): :ex ;;abcl hangs, top shows java activity

Andras

Re: [j-devel] errors are ignored

[Peter Graves <peter@ar...>]

On Sat, 24 Feb 2007 at 14:49:14 +0100, Andras Simon wrote:
> Armed Bear Common Lisp 0.0.9.1+ (built Sat Feb 24 2007 01:38:21 --100)
> Java 1.5.0_08 Sun Microsystems Inc.
> Java HotSpot(TM) Client VM 
> Control-C handler installed.
> Low-level initialization completed in 9.142 seconds. 
> Startup completed in 26.542 seconds.
> Type ":help" for a list of available commands. 
> CL-USER(1): (loop) ;; here I try Ctrl-C, but nothing happens. then
>                     ;; another Ctrl-C gives this:
> Error loading
> /home/simon/java/j2/j/src/org/armedbear/lisp/with-standard-io-syntax.abcl
> at line 3 (offset 52)
> Debugger invoked on condition of type SIMPLE-CONDITION:
>    BREAK called
> Restarts:
>    0: CONTINUE  Return from BREAK.
>    1: CONTINUE  Return from BREAK.
>    2: TOP-LEVEL Return to top level.

Firstly, the Ctrl-C handler is inherently unsafe, since it uses JNI to
install a signal handler which calls back into Java when you press
Ctrl-C. It mostly works, and of course when it does work it's very
useful, but it also crashes Java on occasion; it's not a perfect
solution.

More specifically, I think what's happening when "nothing happens" is
that the Ctrl-C was noticed by the handler, the Java callback was
called, which eventually calls BREAK, but since you're doing this as
the very first thing in a fresh Lisp, a lot of the INVOKE-DEBUGGER
machinery (such as WITH-STANDARD-IO-SYNTAX) needs to be autoloaded
before the debugger message and prompt can be displayed. The second
(and third) Ctrl-C interrupts this autoloading process, and autoloading
is very likely not safe to interrupt in this way.

Another problem is that you seem to be running on a fairly slow machine
(low-level initialization takes 9 seconds), which means all of the
above takes longer, and you're more likely to hit Ctrl-C again. On a
fast machine, there really isn't very much time after the first Ctrl-C
before the debugger prompt appears, so you'd be less likely to hit it
twice.

Finally, there's a new mechanism which I recommend instead of the Ctrl-
C handler if you're using slime-for-emacs and the swank stuff is
running in its own thread: just have that thread call EXT:INTERRUPT-
LISP when you press the key chord mapped to SLIME-INTERRUPT.

EXT:INTERRUPT-LISP does exactly what the Ctrl-C handler's signal
handler does, but without passing through JNI-land, which makes it
somewhat more reliable. As a side benefit, EXT:INTERRUPT-LISP is also
available on Windows, which otherwise would need someone to write a
Windows-specific version of the aforementioned JNI code.

The EXT:INTERRUPT-LISP approach is currently used in slime-for-j (where
SLIME-INTERRUPT is mapped by default to Ctrl Alt B), if you have a very
recent CVS version of j and ABCL.

There might still be a pregnant pause on a slow machinge after Ctrl-
Alt-B if stuff needs to be autoloaded, but the pause will probably be
shorter since loading slime forces more stuff to be loaded to begin
with.

[There might still be a fixable bug or two in this area. Autoloading
could possibly be made safer, and EXT:INTERRUPT-LISP could possibly be
made smarter about which thread to interrupt, if many are running. I
don't plan to look at these issues before releasing 0.0.10, however,
in order to get the release done sooner rather than later.]

-Peter

Re: [j-devel] errors are ignored

[Andras Simon <asimon@ma...>]

On Sat, 24 Feb 2007, Peter Graves wrote:

>
> Firstly, the Ctrl-C handler is inherently unsafe, since it uses JNI to
> install a signal handler which calls back into Java when you press
> Ctrl-C. It mostly works, and of course when it does work it's very
> useful, but it also crashes Java on occasion; it's not a perfect
> solution.
>
> More specifically, I think what's happening when "nothing happens" is
> that the Ctrl-C was noticed by the handler, the Java callback was
> called, which eventually calls BREAK, but since you're doing this as
> the very first thing in a fresh Lisp, a lot of the INVOKE-DEBUGGER
> machinery (such as WITH-STANDARD-IO-SYNTAX) needs to be autoloaded
> before the debugger message and prompt can be displayed. The second
> (and third) Ctrl-C interrupts this autoloading process, and autoloading
> is very likely not safe to interrupt in this way.
>
> Another problem is that you seem to be running on a fairly slow machine
> (low-level initialization takes 9 seconds), which means all of the
> above takes longer, and you're more likely to hit Ctrl-C again. On a
> fast machine, there really isn't very much time after the first Ctrl-C
> before the debugger prompt appears, so you'd be less likely to hit it
> twice.

Out of curiosity, I left ABCL alone for a few hours after starting
(loop) and hitting Ctrl-C once. Still no sign of the debugger
message. Now my machine is indeed very slow, but not _that_ slow :-)
It's as if the first Ctrl-C got buffered (meaning only that it doesn't
get through until something (another Ctrl-C) happens). If I hit Return
or Space before Ctrl-C, then I do get the debugger message imediately.
Though even then, chosing the "Return to toplevel" restart leaves ABCL
hanging.

But what you wrote above about the inherent unsafety of the Ctrl-C
handler is very convincing. So this issue (if it is one) shouldn't
hold back the release.


>
> Finally, there's a new mechanism which I recommend instead of the Ctrl-
> C handler if you're using slime-for-emacs and the swank stuff is
> running in its own thread: just have that thread call EXT:INTERRUPT-
> LISP when you press the key chord mapped to SLIME-INTERRUPT.
>
> EXT:INTERRUPT-LISP does exactly what the Ctrl-C handler's signal
> handler does, but without passing through JNI-land, which makes it
> somewhat more reliable. As a side benefit, EXT:INTERRUPT-LISP is also
> available on Windows, which otherwise would need someone to write a
> Windows-specific version of the aforementioned JNI code.
>
> The EXT:INTERRUPT-LISP approach is currently used in slime-for-j (where
> SLIME-INTERRUPT is mapped by default to Ctrl Alt B), if you have a very
> recent CVS version of j and ABCL.
>
> There might still be a pregnant pause on a slow machinge after Ctrl-
> Alt-B if stuff needs to be autoloaded, but the pause will probably be
> shorter since loading slime forces more stuff to be loaded to begin
> with.
>
> [There might still be a fixable bug or two in this area. Autoloading
> could possibly be made safer, and EXT:INTERRUPT-LISP could possibly be
> made smarter about which thread to interrupt, if many are running. I
> don't plan to look at these issues before releasing 0.0.10, however,
> in order to get the release done sooner rather than later.]

In theory, slime-for-emacs uses EXT:INTERRUPT-THREAD for this purpose.
In practice, it doesn't work... so it's good to know there's an
alternative. (I should add that "doesn't work" refers to
slime-interrupt as implemented using EXT:INTERRUPT-THREAD, not
EXT:INTERRUPT-THREAD itself. There's significant bit-rotting in
slime-for-emacs, and slime-interrupt may be one of its victims.)

Andras