Steel Bank Common Lisp

Lennart Staflin <lenst@...> writes:

> I have compiled sbcl-0.8.7 under Mac OS X 10.2
> (Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003;
> root:xnu/xnu-344.49.obj~2/RELEASE_PPC  Power Macintosh powerpc)
>
> I have a problem with run-program, that probably isn't related to bug
> 190: "PPC/Linux pipe? buffer? bug"

I'm not so sure it's unconnected...

> sbcl would hang in run-program in a state where it didn't respond to
> SIGINT.
>
> With the help of #lisp on irc, I tracked it to a call to
> sb!unix::receive-pending-interrupt, that was recursing
> indefinitely. It seems that a VOP definition is missing for PPC. There
> is a define-vop for do-pending-interrupt, it seems the name was
> changed, but not in all backends. I changed the name in
> ppc/system.lisp and rebuild sbcl. After that run-program no longer
> hangs, but occasionally it signals an error:
>
> * (time (run-program "/bin/sh" '("ls")) )
> debugger invoked on a SIMPLE-ERROR in thread 6058: breakpoint/trap at
> #X22A7720

So what I think is happening here is that the ppc definition of
sigtrap_handler() (in src/runtime/ppc-arch.c) is not right.  There's a
mystified comment just above the trap_PendingInterrupt clause
(probably due for a rename to PENDING_INTERRUPT_TRAP... ;-) which
leads me to suspect that the logic isn't coping with this new demand.
What presumably needs to happen is that if there is a pending
interrupt, we need to skip the breakpoint instruction and handle the
pending interrupt; what's actually currently happening is that we fall
through to the generic debugger.  Something is going wrong somewhere.

If someone has a LinuxPPC machine handy, it might be worth seeing if
bug 190 is altered by this fix; the reason being that gdb works
significantly better there than on MacOS X...  alternatively, if
someone is very confident in their Darwin/gdb abilities, tracking down
register and argument contents in sigtrap_handler at the appropriate
point would be very useful.

Thanks very much for your detective work!

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

Lennart Staflin <lenst@...> writes:

> With the help of #lisp on irc, I tracked it to a call to
> sb!unix::receive-pending-interrupt, that was recursing
> indefinitely. It seems that a VOP definition is missing for PPC. There
> is a define-vop for do-pending-interrupt, it seems the name was
> changed, but not in all backends. I changed the name in
> ppc/system.lisp and rebuild sbcl. 

I've committed this fix for the PPC in sbcl-0.8.7.10, because it's
clearly what was intended.

> After that run-program no longer
> hangs, but occasionally it signals an error:
>
> * (time (run-program "/bin/sh" '("ls")) )
> debugger invoked on a SIMPLE-ERROR in thread 6058: breakpoint/trap at
> #X22A7720

On the only MacOS machine I have access to, I can't reproduce this;
Brian Mastenbrook suggests that this might be because it's a dual
processor machine.

If this is reliably reproducible, it would be very useful to know the
contents of the arguments of sigtrap_handler(); in particular, knowing
the value of the instruction which has caused the fault would be very
useful.  Getting at these things is a little tricky unless you're
fairly comfortable with gdb, though :-/

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

Christophe Rhodes writes:
 > Lennart Staflin <lenst@...> writes:
 > 
 > > With the help of #lisp on irc, I tracked it to a call to
 > > sb!unix::receive-pending-interrupt, that was recursing
 > > indefinitely. It seems that a VOP definition is missing for PPC. There
 > > is a define-vop for do-pending-interrupt, it seems the name was
 > > changed, but not in all backends. I changed the name in
 > > ppc/system.lisp and rebuild sbcl. 
 > 
 > I've committed this fix for the PPC in sbcl-0.8.7.10, because it's
 > clearly what was intended.
 > 
 > > After that run-program no longer
 > > hangs, but occasionally it signals an error:
 > >
 > > * (time (run-program "/bin/sh" '("ls")) )
 > > debugger invoked on a SIMPLE-ERROR in thread 6058: breakpoint/trap at
 > > #X22A7720
 > 
 > On the only MacOS machine I have access to, I can't reproduce this;
 > Brian Mastenbrook suggests that this might be because it's a dual
 > processor machine.

        I did this on my 867 MHz PB12, and saw this behaviour when I
tried to build the contrib stuff. I have some other local
modifications, though, taken from Brian Mastenbrook's web page (the
one with the instructions for building SBCL under Panther and on G5s).

        It seemed that I got a breakpoint every time run-program was
called from make-target-contrib (3 times?)

        I also tried provoking this by calling run-program from the
REPL, and eventually managed to wedge SBCL (the test was something
like "echo hello, world").

Raymond Wiker <Raymond.Wiker@...> writes:

> Christophe Rhodes writes:
>  > On the only MacOS machine I have access to, I can't reproduce this;
>  > Brian Mastenbrook suggests that this might be because it's a dual
>  > processor machine.
>
>         I did this on my 867 MHz PB12, and saw this behaviour when I
> tried to build the contrib stuff. I have some other local
> modifications, though, taken from Brian Mastenbrook's web page (the
> one with the instructions for building SBCL under Panther and on G5s).
>
>         It seemed that I got a breakpoint every time run-program was
> called from make-target-contrib (3 times?)
>
>         I also tried provoking this by calling run-program from the
> REPL, and eventually managed to wedge SBCL (the test was something
> like "echo hello, world").

Well, with the new, more correct RECEIVE-PENDING-INTERRUPT
implementation, what *should* be happening is that the system should
indeed get a SIGTRAP, get into sigtrap_handler (in
src/runtime/ppc-arch.c), and execute the trap_PendingInterrupt case in
the switch statement: move the PC forward over the current
instruction, handle the pending interrupt, and resume execution.

What's actually happening, I don't know.  gdb is the enemy of your
enemy, I'm afraid.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)