OSProcess - working on gnuplot

> On Wed, Nov 18, 2009 at 09:51:24AM +0100, Adrian Lienhard wrote:
>> Hi Dave,
>>
>> Just to make sure I'm looking at the right code: The latest version
>> (for Pharo) are in the projects OSProcess and CommandShell on
>> SqueakSource.com?
>
> Yes, these are the correct versions to use.
>
>> MC complains about missing classes when loading; I
>> just ignored them (probably they are not relevant as they seem  
>> related
>> to the GUI).
>
> These are the MVC user interface classes for CommandShell, and it is
> safe to ignore them. The tests do not required these classes.
>
>>
>> Running all tests crashes the Mac VM.
>
> I have seen crashes on my Linux VM also (testing with an earlier Pharo
> image), although it was not happening yesterday when I was testing.
> Presumably there is inadequate parameter checking in one or more of
> the OSPP primitives, and whatever is going wrong in the tests has
> exposed this.
>
>>
>> But even the simple test of chdir fails:
>>
>> (UnixProcessAccessorTestCase selector: #testChDir) debug
>>
>> It does not seem to invoke any Pharo-specific code. So I wonder if I
>> miss something trivial. UnixOSProcessPlugin.bundle exists in my VM's
>> Contents/Resources/ directory.
>
> I do not have a Mac to test with. I would think that the fact that you
> have gotten the VM to crash is an indication that you have located the
> plugin bundle though ;) Just to double check, try doing this in a
> workspace:
>
>  OSProcess accessor osppModuleVersionString ==> '4.3.3'
>
> The #osppModuleVersionString method will make a call to the plugin
> without doing much else, so that is a way to verify that you have
> loaded the bundle. Also, if the version is not fairly close to the
> latest (4.3.3) it might be an issue.
>
> On OS X, I don't think that you have the AioPlugin or  
> XDisplayControlPlugin
> available, so some of the tests will fail as a result of this. I
> don't have time right now, but I'll try removing these plugins from
> my system and see what happens. But it should be a few simple test
> failures, not the kind of problem you are seeing.
>
> (As a side note, I use a Linux PC, and John and I originally got
> OSProcess working on Mac entirely through email with a bit of
> help from a couple other Mac users. Talk about a lengthy
> edit-compile-test-debug development cycle! But it was a good
> challenge and quite gratifying when we got it all working.).
>
> Thanks,
> Dave
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> On Wed, Nov 18, 2009 at 02:56:56PM +0100, Adrian Lienhard wrote:
>> Hi Dave,
>>
>> OSProcess accessor osppModuleVersionString ==> '4.0.1'
>>
>> I get the same result with the Mac 4.2.2beta1U VM.
>
> I think that's from about November 2005, so a bit out of date. The  
> source
> is on SqueakSource OSProcessPlugin project if you want to see what  
> has changed
> since then. Nevertheless it should still be good enough to get most  
> of the tests
> to pass, so I would not worry about the version difference for now.
>
> Dave
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> OK, I'll stick to this VM version.
>
> I compared to the Squeak trunk image and the very same test cases
> crash the VM. So at least the crashing problem (on Mac) is not likely
> caused by a Pharo-specific change.
>
> Adrian
>
> On Nov 18, 2009, at 16:18 , David T. Lewis wrote:
>
>> On Wed, Nov 18, 2009 at 02:56:56PM +0100, Adrian Lienhard wrote:
>>> Hi Dave,
>>>
>>> OSProcess accessor osppModuleVersionString ==> '4.0.1'
>>>
>>> I get the same result with the Mac 4.2.2beta1U VM.
>>
>> I think that's from about November 2005, so a bit out of date. The
>> source
>> is on SqueakSource OSProcessPlugin project if you want to see what
>> has changed
>> since then. Nevertheless it should still be good enough to get most
>> of the tests
>> to pass, so I would not worry about the version difference for now.
>>
>> Dave
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> I attached gdb to the VM. When running UnixProcessTestCase the VM  
> crashes with:
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000083
> 0x000e7e9d in resume ()
>
> (gdb) bt
> #0  0x000e7e9d in resume ()
> #1  0x4b04264b in ?? ()
> Previous frame inner to this frame (gdb could not unwind past this  
> frame)
>
>
> Adrian
>
> On Nov 18, 2009, at 17:19 , Adrian Lienhard wrote:
>
> > OK, I'll stick to this VM version.
> >
> > I compared to the Squeak trunk image and the very same test cases
> > crash the VM. So at least the crashing problem (on Mac) is not likely
> > caused by a Pharo-specific change.
> >
> > Adrian
> >
> > On Nov 18, 2009, at 16:18 , David T. Lewis wrote:
> >
> >> On Wed, Nov 18, 2009 at 02:56:56PM +0100, Adrian Lienhard wrote:
> >>> Hi Dave,
> >>>
> >>> OSProcess accessor osppModuleVersionString ==> '4.0.1'
> >>>
> >>> I get the same result with the Mac 4.2.2beta1U VM.
> >>
> >> I think that's from about November 2005, so a bit out of date. The
> >> source
> >> is on SqueakSource OSProcessPlugin project if you want to see what
> >> has changed
> >> since then. Nevertheless it should still be good enough to get most
> >> of the tests
> >> to pass, so I would not worry about the version difference for now.
> >>
> >> Dave
> >>

> 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.

> 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 ...

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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.

> Hi Adrian,
>
> Overall, it does look like the basic OSProcess functions that most people
> would use are working as long as an up to date plugin is available.
>
> The remaining issue that is relevant to the Pharo image (as opposed to
> OSProcess running on any other image) is this CommandShellTestCase issue.
> I think we are seeing different, but presumably related, symptoms of some
> underlying problem. The tests in CommandShellTestCase do some rather complex
> things with lots of processes, semaphore synchronization and so on. So I
> think I will need to somehow whittle the problem down to some simpler test
> that can provide some more reproduceable symptoms.
>
> My working assumption is that one of the following is true:
>
> 1) There is something different in Pharo versus Squeak that is exposing
> an existing bug in OSProcess/CommandShell. This is quite likely.
>
> 2) The CommandShellTestCase is exposing an issue in Pharo related to
> Semaphore handling, Delay scheduling, or Process scheduling. The seems
> less likely than #1, but still possible because these tests do drive
> a lot of interacting processes, and might expose an issue the "normal"
> users would never see.
>
> One thing that I know could produce the sort of symptoms that I am seeing
> would be anything that intermittently permitted a signal to a Semaphore
> to be missed. This type of problem causes OSProcess to "miss" the exit
> of one of its external processes, leading to zombie Unix processes and
> tests in Pharo/Squeak that fail to run to completion.
>
> For that reason, if anyone can think of any changes to process scheduling
> and semaphore handling, that might give me an idea of where to look.
>
> Thanks for all the help,
> Dave
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi Dave,
>
> [...]
>
> > The remaining issue that is relevant to the Pharo image (as opposed to
> > OSProcess running on any other image) is this CommandShellTestCase  
> > issue.
>
> I'm not sure about this anymore. I just ran CommandShellTestCase a  
> couple of times in a Squeak trunk image and the third time it also  
> blocked on completionSemaphore. Do you see different problems on Linux?
>

> > I think we are seeing different, but presumably related, symptoms of  
> > some
> > underlying problem. The tests in CommandShellTestCase do some rather  
> > complex
> > things with lots of processes, semaphore synchronization and so on.  
> > So I
> > think I will need to somehow whittle the problem down to some  
> > simpler test
> > that can provide some more reproduceable symptoms.
>
> That would certainly be a good next step!