Adrian,
Thanks *very* much for the detailed feedback. I do want to ask a couple
more questions if your patience holds up.
First question:
I am getting serious failures on CommandShellTestCase that still worry
me. For example, if I evaluate this (on Linux VM with Pharo image):
(CommandShellTestCase selector: #testEvaluateOrMakePipelinesFrom) debug
I find that the test never completes. It is stuck waiting for the various
external processes to be cleaned up, and the console output shows the zombie
processes whose exit signals have not yet been handled by the image:
le...@linux-6xfc:~/squeak/Pharo/pharo1.0-10495-rc1dev09.11.3> ps
PID TTY TIME CMD
3877 pts/51 00:00:00 bash
9695 pts/51 00:00:00 xterm
10060 pts/51 00:00:45 squeakvm
10268 pts/51 00:00:00 ls <defunct>
10269 pts/51 00:00:00 cat <defunct>
10271 pts/51 00:00:00 cat <defunct>
10272 pts/51 00:00:00 wc <defunct>
10273 pts/51 00:00:00 ps <defunct>
10274 pts/51 00:00:00 cat <defunct>
10275 pts/51 00:00:00 cat <defunct>
10279 pts/51 00:00:00 ps
le...@linux-6xfc:~/squeak/Pharo/pharo1.0-10495-rc1dev09.11.3>
Do you see problems like this when you run CommandShellTestCase?
Second question:
Some of the failures you are getting look like things that I thought
that I had fixed in the past (but I'm not sure). The latest versions
from the SqueakSource repositories should be:
OSProcess-dtl.53
Tests-OSProcess-dtl.20
CommandShell-dtl.40
Tests-CommandShell-dtl.14
Could you please double check your versions of OSProcess, CommandShell and
the unit tests to see if they match these MC versions?
Thanks a lot, I really appreciate the help. And obviously I am going to
have to go buy a Mac one of these days so I will not have to ask all
these dumb questions ;)
Dave
On Thu, Nov 19, 2009 at 10:05:26PM +0100, Adrian Lienhard wrote:
> I took another try using a unix VM (3.11.3.2135 compiled from source)
> on OS X 10.5.8. It has the plugin version 4.3.3. Looks much better
> than with the Mac VM that has the outdated plugin!
>
> 409 run, 389 passes, 0 expected failures, 20 failures
>
> - The VM does not crash anymore
> - There are a couple of errors that go away if I change #useOldNetwork
> to return true
>
> - The following tests seem to fail due to assumptions about files and
> permissions that do not hold on OS X:
> ShellSyntaxTestCase>>#testExpandArgument03
> ShellSyntaxTestCase>>#testExpandArgumentFrom01
> UnixProcessAccessorTestCase>>#testIsExecutableForUserInGroup
> UnixProcessAccessorTestCase>>#testIsReadableForUserInGroup
> UnixProcessAccessorTestCase>>#testIsWritableForUserInGroup
> UnixProcessAccessorTestCase>>#testChDir
>
> - one or two tests fail sometimes, but not always. For example:
> UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses04
>
> - The following tests, which fork the VM, do not work:
> PipeableOSProcessTestCase>>#testForkHeadlessSqueak
> PipeableOSProcessTestCase>>#testForkHeadlessSqueak2
> PipeableOSProcessTestCase>>#testForkSqueak
> UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDo
> UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDoThenQuit
> UnixProcessTestCase>>#testClassForkSqueak
> UnixProcessTestCase>>#testClassForkSqueakAndDo
> UnixProcessTestCase>>#testClassForkSqueakAndDoThenQuit
> UnixProcessTestCase>>#testForkHeadlessSqueakAndDo
> UnixProcessTestCase>>#testForkHeadlessSqueakAndDoThenQuit
> UnixProcessTestCase>>#testForkSqueak
> UnixProcessTestCase>>#testForkSqueakAndDo
> UnixProcessTestCase>>#testForkSqueakAndDoThenQuit
> UnixProcessTestCase>>#testHeadlessChild
>
> For example running #testHeadlessChild I get to stdout:
>
> hello world from child process 1359
>
> Segmentation fault
>
> 390493624 UnixProcess>forkHeadlessSqueakAndDoThenQuit:
> 390493524 >forkHeadlessSqueakAndDoThenQuit:
> 390493400 >headlessChild
> 390493264 UnixProcessTestCase>testHeadlessChild
> 390493172 TestCase>executeShould:inScopeOf:
> 390493080 BlockClosure>on:do:
> 390492988 TestCase>executeShould:inScopeOf:
> 390492876 TestCase>shouldnt:raise:
> 390491136 UnixProcessTestCase>testHeadlessChild
> 390491044 TestCase>performTest
> 390490952 TestCase>runCase
>
>
> If I run #testForSqueak I get
>
> The process has forked and you cannot use this CoreFoundation
> functionality safely. You MUST exec().
> Break on
> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
>
> () to debug.
> The process has forked and you cannot use this CoreFoundation
> functionality safely. You MUST exec().
> Break on
> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
>
> () to debug.
> The process has forked and you cannot use this CoreFoundation
> functionality safely. You MUST exec().
> Break on
> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
>
> () to debug.
> The process has forked and you cannot use this CoreFoundation
> functionality safely. You MUST exec().
> Break on
> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
>
> () to debug.
> The process has forked and you cannot use this CoreFoundation
> functionality safely. You MUST exec().
> Break on
> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
>
> () to debug.
> The process has forked and you cannot use this CoreFoundation
> functionality safely. You MUST exec().
> Break on
> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
>
> () to debug.
>
> Segmentation fault
>
> 390953340 DisplayScreen>forceToScreen:
> 390953248 DisplayScreen>forceDamageToScreen:
> 390953124 OrderedCollection>do:
> 390952960 DisplayScreen>forceDamageToScreen:
> 390952840 WorldState>forceDamageToScreen:
> 390869724 WorldState>displayWorld:submorphs:
> 390869632 PasteUpMorph>privateOuterDisplayWorld
> 390869540 PasteUpMorph>displayWorld
> 390869448 WorldState>displayWorldSafely:
> 390869356 BlockClosure>on:do:
> 390869244 BlockClosure>ifError:
> 390869096 WorldState>displayWorldSafely:
>
>
> From these tests it seems that the critical parts of OSProcess are
> actually working with this configuration (modulo the forking).
>
> Adrian
>
> On Nov 19, 2009, at 06:03 , David T. Lewis wrote:
>
> > On Wed, Nov 18, 2009 at 09:44:08PM -0500, David T. Lewis wrote:
> >> On Wed, Nov 18, 2009 at 05:14:04PM -0500, David T. Lewis wrote:
> >>> On Wed, Nov 18, 2009 at 08:55:50AM -0500, Schwab,Wilhelm K wrote:
> >>>> Dave,
> >>>>
> >>>> It would help to knock the MVC workspace out of the offending
> >>>> #initialize
> >>>> method and re-save the packages. In my experience, that simple
> >>>> change make
> >>>> the load hassle-free vs. the current situation.
> >>>
> >>> Bill,
> >>>
> >>> Good idea, thanks. I'll take a look at that when I get home.
> >>
> >> Well actually there were not any MVC references in #initialize. But
> >> CommandShell class>>initialize opens a shell window, and that was
> >> failing
> >> because text style 'Atlanta' no longer exists in Pharo. I fixed this,
> >> so if you update to CommandShell-dtl.40.mcz that failure will no
> >> longer
> >> occur. The shell window does not actually work, but at least the
> >> window
> >> opens properly now. One bug down, ??? to go ...
> >
> > Correction, the shell window *does* seem to be working, so this is
> > actually looking much better now. However, the CommandShellTestCase
> > does not pass (hangs up part way through, lots of zombie unix
> > processes
> > left unhandled).
> >
> > The other unit tests are passing, with the exception of the tests in
> > AioEventHandlerTestCase that use sockets. This is due to changes in
> > the socket support in Pharo, but I am not worried about these failures
> > as they probably just require updates to the tests to match the
> > Pharo socket support.
> >
> > I am testing on Linux with a VM that I built locally. For OS X, an
> > updated OSProcessPlugin will need to be included with the VM,
> > otherwise
> > we will have VM crashes when handling external process exit.
> >
> > The main concerns now are:
> >
> > 1) Need an updated OSProcessPlugin for the Mac VM (for both Squeak
> > and Pharo)
> >
> > 2) Why does CommandShellTestCase on Pharo get hung up and leave
> > zombies?
> >
> > Note, CommandShellTestCase is a real stress test for OSProcess. It
> > does
> > a lot of concurrent process handling with pipelines of OS processes
> > interacting with Squeak/Pharo. If this test does not pass, then I am
> > not confident in the overall reliability of OSProcess.
> >
> > Dave
> >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [email protected]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
