Hi Dave, On Nov 20, 2009, at 02:42 , David T. Lewis wrote:
[...] > 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 Indeed, CommandShellTestCase isn't that stable as I first thought. I've run all tests of CommandShellTestCase in the Test runner multiple times: 1. run: all green 2. run: error in testPipeline75 (re-running this test succeeded, so I don't know what the error was) 3. run: test runner hangs in testIfThenElse02 because indefinitely waiting on completionSemaphore in #evaluatePipelines: restarted the VM 1. run: all green 2. run: same as 3 above 3. run: same as 3 above 4. run: error in testPipeline72 5. run: all green I haven't seen any defunct processes, though. [...] > 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 I have the same versions except for CommandShell-dtl.39 (I updated to 40 now). Let me know if I can be of any more help. Adrian > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
