[squeak-dev] Starting processes from Squeak makes Raspbian
unwilling to start another process
Herbert König
herbertkoenig at gmx.net
Mon Feb 9 14:38:09 UTC 2015
Hi David,
Am 08.02.2015 um 21:04 schrieb David T. Lewis:
> 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".
I see that process while producing Zombies
> 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"
leaves the number of Zombies constant and continues to produce new ones
on each call of ExternalUnixOSProcess>>command
> The actual child watcher process is
> UnixOSProcessAccessor>>grimReaperProcess, so you may want to look at that
That looked like more than I can handle before I'm off again so I tried
something different. On Saturday I had bookmarked:
http://en.wikipedia.org/wiki/Zombie_process
where the fourth paragraph of the overview section talks about sending
SIGCHLD so I tried that.
It works but only adds to the mystery.
For each event in the real world (me moving in front of a PIR sensor) I
send one
PipeableOSProcess command: 'i2cget -y 1 0x20) and two
ExternalUnixOSProcess command: 'i2cset -y 1 0x20', commandByte
This gave me three new Zombies per event. PipeableOSProcess does not
understand sigchld so I only sent sigchld to the two
ExternalUnixOSProcess end expected a reduction to one Zombie per event.
But no more Zombies are produced. We called that "Fehler unerkannt
entkommen" (roughly "the error escaped incognito") and I'm very
interested what happened here.
> 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
Later I'll try to step through grimReaperProcess to see what I can
learn. And then I'll also look at the version of OSProcess you recently
uploaded.
Also the other mystery: When I overflowed the process table I couldn't
from a terminal do 'ls | grep something' but I could do that via
ExternalUnixOSProcess without creating additional Zombies. So which
commands create Zombies and which don't?
Cheers,
Herbert
More information about the Squeak-dev
mailing list
|