[squeak-dev] Starting processes from Squeak makes Raspbian unwilling to start another process

David T. Lewis lewis at mail.msen.com
Sun Feb 8 20:04:31 UTC 2015


Hi Herbert,

On Sat, Feb 07, 2015 at 07:46:43PM +0100, Herbert K??nig wrote:
> Hi,
> 
> now that I noticed the zombies I can experiment much faster so here some 
> further information:
> 
> Stopping Squeak removes all Zombies. Each sensor event creates 3 
> Zombies, two for the I2Csends, one for the I2Cread.
> Sending the PipeableOSProcess instances #closePipes then #release 
> doesn't help.
> Sending the ExternalUnixProcess instances #terminate doesn't help either.
> Sending an additional PipeableOSProcess>>unixCommandPipeLine doesn't add 
> a Zombie but returns ''.
> PipeableOSProcess>>tkExample works fine and doesn't add Zombies.
> 
> So is it a problem of I2Ctools? Should I try other Linux commands?
> 

This looks like some kind of problem in OSProcess. I am not sure what
is wrong, so let me try to explain how it works.

In Unix, a zombie process is a process that has exited, but its parent
process has not yet acknowledged that it has exited. When you run a
command with OSProcess, it starts a new process that is a child of the
VM process. When that external process exits, it is the responsibility
of OSProcess (running in the VM process) to notice this, and to acknowledge
the exit by calling the Unix waitpid() system call.

When things are working right, you should be able to open a process browser
in Squeak, and see an active process labeled "the child OSProcess watcher".
That process is normally blocking on a Semaphore, and it wake up whenever
the semaphore is signalled (which occurs when the OSProcess plugin detects
a SIGCHLD signal from the operating system). Each time it wakes up, it
calls a primitive (UnixOSProcessPlugin>>primitiveReapChildProcess). That
primitive uses a call to waitpid() to obtain the exit status of the child
process, and as soon as that happens the process is no longer in a zombie
state.

I am not sure where this is going wrong, but one thing you can try is
to restart the child watcher process, and see if that makes the zombies
go away:

   "OSProcess accessor restartChildWatcherProcess"

The actual child watcher process is UnixOSProcessAccessor>>grimReaperProcess,
so you may want to look at that and see if it gives you any other ideas.

Please let us know if you figure out the problem. Whatever is going wrong
here, I definitely want to get it fixed.

Thanks,
Dave


> Thanks,
> 
> Herbert
> 
> 
> Am 07.02.2015 um 18:11 schrieb Herbert K??nig:
> >Hi,
> >
> >I managed to make Raspbian unwilling to open any new process. Neither 
> >in the X session, nor from Squeak nor from a SSH session.
> >It seems I create Zombie processes (what is that, in the SSH session I 
> >ran top and it reports thousands of zombies).
> >
> >What I do: I poll a GPIO pin every 100ms. When it is high I query I2C 
> >via:
> >(PipeableOSProcess command: 'i2cget -y ', busNo, ' ', address) output
> >
> >and when I find a certain bit set, I switch on some LEDs via:
> >current := ExternalUnixOSProcess command: 'i2cset -y ', busNo, ' ', 
> >address, ' ', aString.
> >OSProcess thisOSProcess unregisterChildProcess: current. "This doesn't 
> >unregister the process?????"
> >current := nil.
> >
> >I found 2700++ instances of ExternalOSProcess, emptied the Dictionary 
> >via UnixProcess>>unregisterChildProcess and it stopped when it 
> >accumulated to another 900+ instances.
> >
> >This ran for half a day until It can't start another process. First I 
> >thought this was the Raspbian update for the PasPi B2 but now I 
> >reproduced it on a Pi A+ last updated mid January.
> >
> >Having read Wikipedia on Zombie Process it seems, that I should try to 
> >kill each process I started?
> >What do I do to the PipeableOSProcess? closePipes? release?
> >
> >Thanks,
> >
> >Herbert
> >
> >
> >
> >
> 


More information about the Squeak-dev mailing list