On Tue, Jan 26, 2010 at 06:32:43PM -0700, Mike Hales wrote:
On Tue, Jan 26, 2010 at 3:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jan 26, 2010 at 08:19:14PM -0200, Jecel Assumpcao Jr wrote:
David,
I took a quick look on a quad core 2 box running Fedora Core 10 and the Squeak 3.7-7 VM and 3.10.2 image. It seems to lock up on "RemoteTask result". Running the Tests-OSProcess does indeed cause one failure in #testCooperatingProcesses04 where the tests for version 43 were all green. Running Tests-CommandShell locks up after 71 tests with one failure (version 4.3 had all green tests after I created a /usr/bin/vi file).
Jecel,
Thanks very much for trying this and for the feedback. I guess it's about time I replaced my ten year old computer so I can test this myself. I am guessing that a possible culprit is signal delivery for the SIGCHLD handler, I wonder if that might behave a little differently on a multi-core machine ...
Thanks again,
Dave
I tried it on my dual core intel mac (older 32 bit one), and the VM (Squeak4.3.1 Beta1U) crashed. So I loaded the OSProcess tests into an up to date trunk image, and running the tests in UnixProcessTestCase crashed the VM. This also happens in the Pharo Dev 1.0 RC2.
Mike,
Urk. I guess I aught to get a Mac Mini one of these days too so I can try things on Mac. I'm not sure how solid this is on Pharo by the way; I know that the CommandShell tests (which do a lot of process scheduling) have problems, and I suspect that there are some things in the OSProcess / CommandShell tests that are timing dependent and for some reason get flaky on the Pharo images. Sorry I can't be more specific.
Obviously crashing the VM is not acceptable regardless of what the application is doing, so something is badly wrong here.
Thanks for trying this and also for the feedback.
Dave