On Thu, Dec 27, 2007 at 11:38:31AM -0800, John M McIntosh wrote:
> Ok, I did a bit more poking at this yesterday and find all the  
> pipeline tests fail on powerpc 10.4.11. I'm not sure why, oddly it  
> sometimes works so there must be some timing issue? In cross checking  
> I can occasionally get the macintel 10.5.1 version to crash the VM

It's entirely possible that there are timing issues. The
CommandShellTestCase tests (and CommandShell in general) use
lots of Processes both in the command pipelines themselves, and
in the buffered async I/O streams that are used for the pipes.
It took quite a while to get this running reliably, and even
now I will occasionally get test failures when running the full
test suite even though the individual tests run without problems.
So I would not be entirely surprised if a different combination
of hardware speed and VM were to flush out one or two more glitches.
Also, there has been a fair amount of discussion about patches
to Delay and friends on the Seaside list, and I would not be
surprised if the CommandShell test suite is vulnerable to some
of those same issues.

> However i'll note running the powerpc version under gdb works fine.  
> Could it be that running as a double-clicked application stdin/stdout  
> isn't opened and causing issues?

I guess it's possible. I don't know where those streams get redirected
when running as a "normal" Mac application, but anything that affects
timing and overall performance of the VM might have an effect.

One other thing that I use as an overall torture test for CommandShell
is to open two or three command shell windows, and in each of them
run the command "$ ls -lR /". This generates tons of I/O and window
updating. If you leave these running to completion without getting
a red window of death then things are looking pretty good.

Note: Use <ctl>C in the command window to interrupt the "ls -lR /"
process when you get tired of watching it. Also with respect to
<ctl>C events, note Mantis <http://bugs.squeak.org/view.php?id=6827>.
My current workaround for this in CommandShell causes the copy
text shortcut to be broken in a command shell, but does ensure
that you can use <ctl>C to interrupt long running external processes
from the command shell.

Dave