A problem with startUp messages
Kevin Fisher
kgf at golden.net
Thu Jun 28 01:30:44 UTC 2001
Hi folks:
I've been working with David Lewis, trying to figure out why OSProcess has
been leaving behind <defunct> zombie processes. It turns out, the problem
isn't with OSProcess at all...
In my image, the SystemDictionary's StartUpList has UnixOSProcessAccessor
later in the ordered collection, after SecurityManager. When the image gets
restarted, only classes iterated over the StartUpList up to and including
SecurityManager receive the startUp message. After that, SystemDictionary>>
send:toClassesNamedIn:with: terminates prematurely, leaving several classes
not restarted (including UnisOSProcessAccessor, the source of the OSProcess
zombies). Actually I'm not sure it terminates at all, it seems to get stuck
at SecurityManager.
It looks as though SecurityManager class>>startUp never returns...but only
during startup. Once the image is up and running, doing a SecurityManager
startUp seems to work just fine...it's only during the startup that something
funny happens. The trick is to put Transcript show: scaffolding around 'self
default startUp' in SecurityManager class>>startUp...open a Transcript, save
the image and quit, reload and watch what gets put in the Transcript. The
first Transcript show: will appear, but the second does not. However, once
the image is up, doing a SecurityManager startUp will show both Transcript
show: 's. Perhaps some sort of deadlock is happening during the restart of
the image?
I'm a bit stumped at this point...any ideas? This is on the UNIX VM, with the
latest changes in the 3.1 image.
More information about the Squeak-dev
mailing list
|