On Thu, May 17, 2012 at 09:54:11AM -0700, Yoshiki Ohshima wrote:
> At Thu, 17 May 2012 10:16:53 -0400,
> David T. Lewis wrote:
> > 
> > On Wed, May 16, 2012 at 07:38:36PM -0700, Yoshiki Ohshima wrote:
> > > At Wed, 16 May 2012 19:47:15 -0400,
> > > David T. Lewis wrote:
> > > > 
> > > > On Wed, May 16, 2012 at 12:53:26PM -0700, Yoshiki Ohshima wrote:
> > > > >   Thank you, Dave!
> > > > > 
> > > > > I now understand that going through CommandShell was the sanctioned
> > > > > way of using PipeableOSProcess.  I'll just modify our code to close it
> > > > > explicitly.  (And it seems to work beter.)
> > > > > 
> > > > > I tried clearing the allMyChildren directory but did not seem to free
> > > > > these fds.  I tried:
> > > > > 
> > > > > PipeableOSProcess allSubInstancesDo: [:e | e closePipes]
> > > > > 
> > > > > but this do it seems to kill the VM.
> > > > 
> > > > Eeek! This should not be happening. PipeableOSProcess>>closePipes uses
> > > > StandardFileStream>>primCloseNoError: which does an fclose() to close
> > > > the pipe descriptor. This should be failure-proof, but I might be missing
> > > > something.
> > > > 
> > > > Is this reproduceable? It does not seem to happen on my Linux PC, but
> > > > maybe it is an intermittent failure of some kind.
> > > 
> > > This is reproduceable in my combination of things.  It does not have
> > > to be allSubInstancesDo:, but allInstancesDo: does it (of course).
> > > 
> > > Oh, the trick seems that I shouldn't close the notifier.  Do the
> > > first part:
> > > -------------------------
> > > v := [1 to: 256 do: [:i |
> > > 		(PipeableOSProcess command: 'echo hello') output.
> > > 		(Delay forMilliseconds: 50) wait.]].
> > > v fork.
> > > -------------------------
> > > 
> > > and while the notifier is shown on the screen, evaluate:
> > > 
> > > -------------------------
> > > PipeableOSProcess allInstancesDo: [:e | e closePipes]
> > > -------------------------
> > > 
> > 
> > Thanks Yoshiki,
> > 
> > I see it now. I cannot explain what is happening. The system is
> > behaving as if the VM was blocked on a read, but I don't think
> > that this is the actual problem. Interesting ...
> 
> Just another data point: the crash report shows that VM is blocked on
> a read on Mac, too.
> 
> -- Yoshiki

The Cog VM produces a very useful stack dump that confirms that the VM
is blocking on a read from an OS pipe. I cannot explain exactly how we
are reaching this state, but apparently closing all those pipe handles
with "PipeableOSProcess allInstancesDo: [:e | e closePipes]" is not a
good thing to do while the debugger window is open ;)

Dave


SIGUSR1 Thu May 17 21:51:17 2012


Squeak VM version: 4.0-2550 #12 Wed Apr 18 09:27:54 PDT 2012 gcc 4.1.2
Built from: CoInterpreter VMMaker.oscog-eem.157 uuid: 9a11acbe-4a62-43ce-81de-934f351598cc Apr  4 2012
With: StackToRegisterMappingCogit VMMaker.oscog-eem.157 uuid: 9a11acbe-4a62-43ce-81de-934f351598cc Apr  4 2012
Revision: VM: r2550 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins
Build host: Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009 i686 i686 i386 GNU/Linux
plugin path: /usr/local/bin/../lib/squeak/4.0-2550 [default: /usr/local/lib/squeak/4.0-2550/]


C stack backtrace:
/usr/local/bin/../lib/squeak/4.0-2550/squeak[0x805b821]
/usr/local/bin/../lib/squeak/4.0-2550/squeak[0x805ba8d]
[0xffffe410]


All Smalltalk process stacks (active first):
Process 0xc0c32e28 priority 40
0xff7d4914 M AttachableFileStream(StandardFileStream)>readInto:startingAt:count: -1053201620: a(n) AttachableFileStream
0xff7d493c M AttachableFileStream(StandardFileStream)>next:into:startingAt: -1053201620: a(n) AttachableFileStream
0xff7d4960 M AttachableFileStream(PositionableStream)>nextInto: -1053201620: a(n) AttachableFileStream
0xff7d4988 M AttachableFileStream>upToEnd -1053201620: a(n) AttachableFileStream
0xff7d49a0 M ExternalPipe>upToEnd -1053201688: a(n) ExternalPipe
0xff7d49c0 M [] in PipeableOSProcess>closePipes -1053202016: a(n) PipeableOSProcess