Warning Zombie SUnitBrowsers detected

Can someone help me with this warning?

Thanks

Alex Peake wrote:

> Can someone help me with this warning?

It's probably coming from SmalltalkToolShell class>>showExistingInstance.

If so, then what's happening is that you've got the #reuseIfOpen property of
SUnitBrowser turned on (as it is by default), so when you attempt to open an
SUnitBrowser the system checks to see if one is already open.  That check is
implemented in the above method; it looks to find any existing instances and,
if it finds on, it brings it to the front instead of starting a new one.  It
also does a bit of sanity checking for Views that have been partially opened or
improperly shutdown; if it finds any then it cleans them up but also writes the
warning message to the Transcript.

Normally the reason you'd get such zombies is that something went wrong during
initialisation of a View, resulting in a walkback and/or debugger session.  If
you terminate that then you can end up with a zombie View.  An easy way to
check for them is to look at the third segment of the 'Window' menu in any
Dolphin tool window.  Such views will be marked 'hidden', and when you use the
menu to show them, the window turns out to be "dead".  Killing the "dead"
window will purge the ghost.

Not something to worry about unless it is happening persistently.  Is it ?

    -- chris

"Chris Uppal" wrote:

> It's probably coming from SmalltalkToolShell class>>showExistingInstance.
>
> If so, then what's happening is that you've got the #reuseIfOpen property
of
> SUnitBrowser turned on (as it is by default), so when you attempt to open
an
> SUnitBrowser the system checks to see if one is already open.  That check
is
> implemented in the above method; it looks to find any existing instances
and,
> if it finds on, it brings it to the front instead of starting a new one.
It
> also does a bit of sanity checking for Views that have been partially
opened or
> improperly shutdown; if it finds any then it cleans them up but also
writes the
> warning message to the Transcript.
>
> Normally the reason you'd get such zombies is that something went wrong
during
> initialisation of a View, resulting in a walkback and/or debugger session.
If
> you terminate that then you can end up with a zombie View.  An easy way to
> check for them is to look at the third segment of the 'Window' menu in any
> Dolphin tool window.  Such views will be marked 'hidden', and when you use
the
> menu to show them, the window turns out to be "dead".  Killing the "dead"
> window will purge the ghost.
>
> Not something to worry about unless it is happening persistently.  Is it ?
>
>     -- chris
>
Thanks for the reply Chris.

It happens when I open an image of my current work (in the Sytem
Transcript).
There is nothing showing (of interest) in the 'Window' menu.
I tried SmalltalkToolShell class>>showExistingInstance and it returned nil.

Not critical -- I can start again this time, but I am curious how to get rid
of it for the future when start again is not so easy.

Alex

Alex Peake wrote:

> It happens when I open an image of my current work (in the Sytem
> Transcript).
> There is nothing showing (of interest) in the 'Window' menu.
> I tried SmalltalkToolShell class>>showExistingInstance and it returned
> nil.

You mean that each time you restart your saved image you get a *new* message in
the Transcript ?  If so then that is rather odd, and I have no idea what might
be causing it.

You could try:

    SUnitBrowser allInstances do: [:each | each close].

to get rid of it.  I get the impression that sending #close to a View is rather
more terminal than sending #release which is what SmalltalkToolShell
class>>showExistingInstance does.  That's effectively the same as hitting the
"panic" button except that it's limited to SUnitBrowsers, rather than closing
all your other windows.

You could also try closing any working SUnitBrowser, and then using
SUnitBrowser allInstances and #allReferences to find out what is holding on to
an anomalous reference to it.  You could also try the ReferenceFinder from the
RB to try to track down the same info more conveniently -- I haven't had much
luck with it myself*, but it may work for you.

    -- chris

[*] I think there must be some roots that it doesn't consider, or some paths
that it doesn't follow, because I find that it claims that there are no paths
to objects that I *know* are lurking in the image -- I've never taken the time
to investigate properly, though.