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
Mike Hales Engineering Manager KnowledgeScape www.kscape.com
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
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
On Wed, Jan 27, David T. Lewis wrote:
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.
Obviously crashing the VM is not acceptable regardless of what the application is doing, so something is badly wrong here.
As far as I can tell, the Cocoa and Carbon VMs do not ship with pre-built plugins necessary for OSProcess. I naively tried David's test with a couple and crashed the VM each time. Mike, did you build your own OSProcess and AIO plugins?
(I tried one of Ian Piumarta's Unix VMs for Darwin, because it came with pre-built plugins, and it didn't crash the VM, but several of the tests in Test-OSProcess failed. I chose not to document it or pursue it further, partly because Mac OS X 10.4 is not supported by recent VMs.)
David: which image and VM did you use?
I did not build my own. I did look in the vm app resources, and there is a UnixOSProcessPlugin.bundle. There is definately not an AIO plugin though, and I did get a pop-up saying AIO was not found, using polling instead.
Mike
Mike Hales Engineering Manager KnowledgeScape www.kscape.com
On Thu, Jan 28, 2010 at 9:10 AM, David Corking lists@dcorking.com wrote:
On Wed, Jan 27, David T. Lewis wrote:
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.
Obviously crashing the VM is not acceptable regardless of what the
application
is doing, so something is badly wrong here.
As far as I can tell, the Cocoa and Carbon VMs do not ship with pre-built plugins necessary for OSProcess. I naively tried David's test with a couple and crashed the VM each time. Mike, did you build your own OSProcess and AIO plugins?
(I tried one of Ian Piumarta's Unix VMs for Darwin, because it came with pre-built plugins, and it didn't crash the VM, but several of the tests in Test-OSProcess failed. I chose not to document it or pursue it further, partly because Mac OS X 10.4 is not supported by recent VMs.)
David: which image and VM did you use?
On Thu, Jan 28, 2010 at 04:10:55PM +0000, David Corking wrote:
On Wed, Jan 27, David T. Lewis wrote:
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.
Obviously crashing the VM is not acceptable regardless of what the application is doing, so something is badly wrong here.
As far as I can tell, the Cocoa and Carbon VMs do not ship with pre-built plugins necessary for OSProcess. I naively tried David's test with a couple and crashed the VM each time. Mike, did you build your own OSProcess and AIO plugins?
(I tried one of Ian Piumarta's Unix VMs for Darwin, because it came with pre-built plugins, and it didn't crash the VM, but several of the tests in Test-OSProcess failed. I chose not to document it or pursue it further, partly because Mac OS X 10.4 is not supported by recent VMs.)
David: which image and VM did you use?
I am using a 3.11.12-2146 VM compiled in 64-bit mode on my AMD-64 laptop with Linux, and a Squeak trunk image. This is a slow single-core CPU.
In testing OSProcess and CommandShell, I will occasionally get test failures on one of the CommandShell or file lock tests. This is apparently due to timing variations in some of the tests that depend on synchronization of lots of external processes.
Last I checked, the CommandShell tests have problems on a Pharo image. Again this is probably timing related, although I suspect that that heavy process switching in the CommandShell tests may be exposing an issue in the Pharo image (I'm not at all certain of other root cause here).
I don't know how reliable this is on OS X. I know that most OSProcess functions work on OS X, but I'm not sure how solid the #forkSqueak is. AioPlugin is not included on OS X, although I expect that it would work if you try compiling it, because the Mac and Unix VMs share the same aio functions in the support code.
Dave
On Fri, Jan 29, David T. Lewis wrote:
I am using a 3.11.12-2146 VM compiled in 64-bit mode on my AMD-64 laptop with Linux, and a Squeak trunk image. This is a slow single-core CPU.
That is some very new code. Therefore I suspect my mileage will improve when I upgrade this dual-core Intel Mac to Linux or a recent OS X (rather than persevering with an unsupported version of Mac OS X. Darwin's binary loader changed circa 2008, among other things, so running the latest Xcode with an older Mac as target requires special care and feeding.)
I don't know how reliable this is on OS X. I know that most OSProcess functions work on OS X, but I'm not sure how solid the #forkSqueak is.
That will be very interesting to drill into (when I get the tax returns done :( ) I'm afraid I didn't know OSProcess could fork a Squeak until your post on Tuesday.
AioPlugin is not included on OS X, although I expect that it would work if you try compiling it, because the Mac and Unix VMs share the same aio functions in the support code.
The darwin builds of the Unix VM have AioPlugin. I assume your demo won't work with the fallback I/O protocol.
David
squeak-dev@lists.squeakfoundation.org
-
David Corking -
David T. Lewis -
Mike Hales