Bad window management [VW7.4]

> Try Terry's correction, posted here 27.4.06.
> http://www.parcplace.net/list/vwnc-archive/0604/msg00342.html
> (See Attachment link at the bottom of that page)
>
> We saw the same thing, and normally it was the #debugger key in the
> ProcessEnvironment of a debugger's WindowManager process that was the
> culprit. In those cases something really was hanging on to them, and the
> fix corrects that.
>
> Even after that fix we still see a similar program with weakly held
> objects not being gc'd - or to be more accurate, Trippy's / AT System
> Analysis' Browse Reference Paths shows no reference paths to the
> objects, but they are not gc'd. As you say, opening a Process Monitor
> clears things up; the shortest code to run to clear things up is:
>
> WindowManager purgeDeadWindows
>
> I've tried to find what holds these objects, and why doing the above
> helps, but couldn't so far. We've had this problem since 7.1; it wasn't
> in 3.0. My suspicion has been a problem in finalization, but I've yet to
> find the smoking gun!

>>-----Original Message-----
>>From: Ladislav Lenart [mailto:[hidden email]]
>>Sent: 10 May 2006 19:18
>>To: vwnc
>>Subject: Bad window management [VW7.4]
>>
>>Hi,
>>
>>we use WeakAnnouncements (only) and we encountered a strange behavior
>
> of
>
>>windows
>>as a side effect when running our tests.
>>
>>When we run all our tests which havily rely on announcements we end up
>>with
>>several thousands subscribers (SubscriptionRegistry.Registries size).
>
> When
>
>>we do garbage collect afterwards, all these subscribers and their
>>subscription
>>registries are gc'ed.
>>
>>But when a test fails during a run and we terminate it, then some
>>subscriptions survive any
>>number of garbage collections.
>>
>>And the strangest bit at the end: all you have to do to get rid of
>
> such
>
>>survivors
>>is to open a window which has its own window manager (e.g. new
>
> Workspace,
>
>>Process
>>Monitor, ...) and then invoke garbage collection...
>>
>>It seems that closed (debugger?) windows are somehow referenced by
>
> their
>
>>window
>>manager, but we haven't found how, because when we inspect window
>
> managers
>
>>(WindowManager.ManagerRegistry), they are either empty or reference
>
> living
>
>>windows.
>>
>>BTW does anybody now why there is so many window managers each with
>
> one
>
>>FlyByHelpWindow?
>>
>>Ladislav Lenart

> -----Original Message-----
> From: Ladislav Lenart [mailto:[hidden email]]
> Sent: 11 May 2006 11:18
> To: vwnc
> Subject: Re: Bad window management [VW7.4]
>
> Steven Kelly wrote:
> > Try Terry's correction, posted here 27.4.06.
> > http://www.parcplace.net/list/vwnc-archive/0604/msg00342.html
> > (See Attachment link at the bottom of that page)
> >
> > We saw the same thing, and normally it was the #debugger key in the
> > ProcessEnvironment of a debugger's WindowManager process that was

> > find the smoking gun!
>
> I am afraid that this has nothing to do with bug in finalization but
> rather with fact
> that windows run in separate processes since VW7.1...
>
> What about this explanation:
>
> Each WindowManager manages its windows and runs in its own process (iv
> baseProcess).
> The code you mentioned earlier, that is
> WindowManager purgeDeadWindows
> is called each time a new WindowManager is being added to

> was wrong... :-(
>
> Ladislav Lenart
>
> >>-----Original Message-----
> >>From: Ladislav Lenart [mailto:[hidden email]]
> >>Sent: 10 May 2006 19:18
> >>To: vwnc
> >>Subject: Bad window management [VW7.4]
> >>
> >>Hi,
> >>
> >>we use WeakAnnouncements (only) and we encountered a strange

> >
> > When
> >
> >>we do garbage collect afterwards, all these subscribers and their
> >>subscription
> >>registries are gc'ed.
> >>
> >>But when a test fails during a run and we terminate it, then some
> >>subscriptions survive any
> >>number of garbage collections.
> >>
> >>And the strangest bit at the end: all you have to do to get rid of
> >
> > such
> >
> >>survivors
> >>is to open a window which has its own window manager (e.g. new
> >
> > Workspace,
> >
> >>Process
> >>Monitor, ...) and then invoke garbage collection...
> >>
> >>It seems that closed (debugger?) windows are somehow referenced by
> >
> > their
> >
> >>window
> >>manager, but we haven't found how, because when we inspect window
> >
> > managers
> >
> >>(WindowManager.ManagerRegistry), they are either empty or reference
> >
> > living
> >
> >>windows.
> >>
> >>BTW does anybody now why there is so many window managers each with
> >
> > one
> >
> >>FlyByHelpWindow?
> >>
> >>Ladislav Lenart
>

> -----Original Message-----
> From: Steven Kelly [mailto:[hidden email]]
> Sent: Thursday, May 11, 2006 4:45 AM
> To: vwnc
> Subject: RE: Bad window management [VW7.4]
>
> If the objects were being held through the ProcessEnvironment of the
> baseProcess of a WindowManager that is still in the ManagerRegistry,
> they would still show up in "Inspect Reference Paths". That's what was
> happening with the #debugger key. So no, it seems your suggested
> explanation cannot hold for our case.
>
> I wonder if it's possible that although the WindowManager has been
> removed from ManagerRegistry, its process has not been terminated? Maybe
> such an orphan process wouldn't show up in Inspect Reference Paths, but
> wouldn't be gc'd either. But then that wouldn't explain why
> #purgeDeadWindows helps...
>
> This problem has been around since I started using VW versions with
> finalization and WindowManager. The objects seem to remain because
> they're not being finalized, and a WindowManager call cleans them up. It
> looks like one or both of finalization and WindowManager may be
> implicated. It's only circumstantial evidence, but it's been really
> difficult to collect more. And since the response from the people who
> wrote the code has often been "no, that can't happen", it's been kind of
> tricky to get anything to happen. Kudos to Terry for fixing the related
> #debugger problem!
>
> Steve
>
> > -----Original Message-----
> > From: Ladislav Lenart [mailto:[hidden email]]
> > Sent: 11 May 2006 11:18
> > To: vwnc
> > Subject: Re: Bad window management [VW7.4]
> >
> > Steven Kelly wrote:
> > > Try Terry's correction, posted here 27.4.06.
> > > http://www.parcplace.net/list/vwnc-archive/0604/msg00342.html
> > > (See Attachment link at the bottom of that page)
> > >
> > > We saw the same thing, and normally it was the #debugger key in the
> > > ProcessEnvironment of a debugger's WindowManager process that was
> the
> > > culprit. In those cases something really was hanging on to them, and
> the
> > > fix corrects that.
> > >
> > > Even after that fix we still see a similar program with weakly held
> > > objects not being gc'd - or to be more accurate, Trippy's / AT
> System
> > > Analysis' Browse Reference Paths shows no reference paths to the
> > > objects, but they are not gc'd. As you say, opening a Process
> Monitor
> > > clears things up; the shortest code to run to clear things up is:
> > >
> > > WindowManager purgeDeadWindows
> > >
> > > I've tried to find what holds these objects, and why doing the above
> > > helps, but couldn't so far. We've had this problem since 7.1; it
> wasn't
> > > in 3.0. My suspicion has been a problem in finalization, but I've
> yet to
> > > find the smoking gun!
> >
> > I am afraid that this has nothing to do with bug in finalization but
> > rather with fact
> > that windows run in separate processes since VW7.1...
> >
> > What about this explanation:
> >
> > Each WindowManager manages its windows and runs in its own process (iv
> > baseProcess).
> > The code you mentioned earlier, that is
> > WindowManager purgeDeadWindows
> > is called each time a new WindowManager is being added to
> ManagerRegistry,
> > that is
> > each time a new Window with its own WindowManager is being opened
> (e.g.
> > ProcessMonitor).
> > Now the manager without windows finally realizes its situation and
> > terminates itself.
> > The terminate consists of first removing from ManagerRegistry and then
> > terminating the
> > baseProcess (if any). And because the baseProcess holds something in
> its
> > environment
> > that holds everything else, it can all be gc'ed only *after*
> termination
> > of the window
> > manager...
> >
> > I thought that I saw all nasty guts of VW but once again it turned out
> I
> > was wrong... :-(
> >
> > Ladislav Lenart
> >
> > >>-----Original Message-----
> > >>From: Ladislav Lenart [mailto:[hidden email]]
> > >>Sent: 10 May 2006 19:18
> > >>To: vwnc
> > >>Subject: Bad window management [VW7.4]
> > >>
> > >>Hi,
> > >>
> > >>we use WeakAnnouncements (only) and we encountered a strange
> behavior
> > >
> > > of
> > >
> > >>windows
> > >>as a side effect when running our tests.
> > >>
> > >>When we run all our tests which havily rely on announcements we end
> up
> > >>with
> > >>several thousands subscribers (SubscriptionRegistry.Registries
> size).
> > >
> > > When
> > >
> > >>we do garbage collect afterwards, all these subscribers and their
> > >>subscription
> > >>registries are gc'ed.
> > >>
> > >>But when a test fails during a run and we terminate it, then some
> > >>subscriptions survive any
> > >>number of garbage collections.
> > >>
> > >>And the strangest bit at the end: all you have to do to get rid of
> > >
> > > such
> > >
> > >>survivors
> > >>is to open a window which has its own window manager (e.g. new
> > >
> > > Workspace,
> > >
> > >>Process
> > >>Monitor, ...) and then invoke garbage collection...
> > >>
> > >>It seems that closed (debugger?) windows are somehow referenced by
> > >
> > > their
> > >
> > >>window
> > >>manager, but we haven't found how, because when we inspect window
> > >
> > > managers
> > >
> > >>(WindowManager.ManagerRegistry), they are either empty or reference
> > >
> > > living
> > >
> > >>windows.
> > >>
> > >>BTW does anybody now why there is so many window managers each with
> > >
> > > one
> > >
> > >>FlyByHelpWindow?
> > >>
> > >>Ladislav Lenart
> >

> A few weeks ago Steve posted a script that would reproduce
> the bug, or at least part of the bug. Using that script
> I found out that the window manager ended up waiting on
> the event queue for an event but the manager did not have
> any windows to manage. I don't know how it gets into this
> situation but it was not too difficult to fix. My fix was
> predicated on the idea that once a window manager has a
> window to manage, it must always have a window to manage.
> If it no longer has a window then it terminates itself.
> So, before waiting on the event queue it first checks to
> see if it is managing any windows.
>
> When Steve first reported this he noted that he saw 2
> zombie window managers. When I ran his script I saw only
> 1 zombie window manager. My fix addressed that problem.
>
> I don't think the problem that Steve still sees is a
> finalization problem. All too often in the past I have
> seen the reference path tool miss a path, so when it does
> not find a path, I don't completely trust it.
>
> I would recommend that Ladislav apply the posted patch
> and see if it fixes his problem.

> -----Original Message-----
> From: Steven Kelly [mailto:[hidden email]]
> Sent: Wednesday, May 10, 2006 12:37 PM
> To: vwnc
> Subject: RE: Bad window management [VW7.4]
>
> Try Terry's correction, posted here 27.4.06.
> http://www.parcplace.net/list/vwnc-archive/0604/msg00342.html
> (See Attachment link at the bottom of that page)
>
> We saw the same thing, and normally it was the #debugger key in the
> ProcessEnvironment of a debugger's WindowManager process that was the
> culprit. In those cases something really was hanging on to them, and the
> fix corrects that.
>
> Even after that fix we still see a similar program with weakly held
> objects not being gc'd - or to be more accurate, Trippy's / AT System
> Analysis' Browse Reference Paths shows no reference paths to the
> objects, but they are not gc'd. As you say, opening a Process Monitor
> clears things up; the shortest code to run to clear things up is:
>
> WindowManager purgeDeadWindows
>
> I've tried to find what holds these objects, and why doing the above
> helps, but couldn't so far. We've had this problem since 7.1; it wasn't
> in 3.0. My suspicion has been a problem in finalization, but I've yet to
> find the smoking gun!
>
> Steve
>
> > -----Original Message-----
> > From: Ladislav Lenart [mailto:[hidden email]]
> > Sent: 10 May 2006 19:18
> > To: vwnc
> > Subject: Bad window management [VW7.4]
> >
> > Hi,
> >
> > we use WeakAnnouncements (only) and we encountered a strange behavior
> of
> > windows
> > as a side effect when running our tests.
> >
> > When we run all our tests which havily rely on announcements we end up
> > with
> > several thousands subscribers (SubscriptionRegistry.Registries size).
> When
> > we do garbage collect afterwards, all these subscribers and their
> > subscription
> > registries are gc'ed.
> >
> > But when a test fails during a run and we terminate it, then some
> > subscriptions survive any
> > number of garbage collections.
> >
> > And the strangest bit at the end: all you have to do to get rid of
> such
> > survivors
> > is to open a window which has its own window manager (e.g. new
> Workspace,
> > Process
> > Monitor, ...) and then invoke garbage collection...
> >
> > It seems that closed (debugger?) windows are somehow referenced by
> their
> > window
> > manager, but we haven't found how, because when we inspect window
> managers
> > (WindowManager.ManagerRegistry), they are either empty or reference
> living
> > windows.
> >
> > BTW does anybody now why there is so many window managers each with
> one
> > FlyByHelpWindow?
> >
> > Ladislav Lenart

> -----Original Message-----
> From: Terry Raymond [mailto:[hidden email]]
> Sent: 11 May 2006 21:50
> To: 'vwnc'
> Subject: RE: Bad window management [VW7.4]
>
> Steve
>
> The only other way I can think of the reference path
> collector not finding a path to an object is that the
> path goes through an ObsoleteClass.
>
> Do you have any obsolete classes in your image? If so,
> I suggest that you purge them out and then try your test
> case.
>
> Terry
>
> ===========================================================
> Terry Raymond       Smalltalk Professional Debug Package
> Crafted Smalltalk
> 80 Lazywood Ln.
> Tiverton, RI  02878
> (401) 624-4517      [hidden email]
> <http://www.craftedsmalltalk.com>
> ===========================================================
>
> > -----Original Message-----
> > From: Steven Kelly [mailto:[hidden email]]
> > Sent: Wednesday, May 10, 2006 12:37 PM
> > To: vwnc
> > Subject: RE: Bad window management [VW7.4]
> >
> > Try Terry's correction, posted here 27.4.06.
> > http://www.parcplace.net/list/vwnc-archive/0604/msg00342.html
> > (See Attachment link at the bottom of that page)
> >
> > We saw the same thing, and normally it was the #debugger key in the
> > ProcessEnvironment of a debugger's WindowManager process that was

> > find the smoking gun!
> >
> > Steve
> >
> > > -----Original Message-----
> > > From: Ladislav Lenart [mailto:[hidden email]]
> > > Sent: 10 May 2006 19:18
> > > To: vwnc
> > > Subject: Bad window management [VW7.4]
> > >
> > > Hi,
> > >
> > > we use WeakAnnouncements (only) and we encountered a strange

> > When
> > > we do garbage collect afterwards, all these subscribers and their
> > > subscription
> > > registries are gc'ed.
> > >
> > > But when a test fails during a run and we terminate it, then some
> > > subscriptions survive any
> > > number of garbage collections.
> > >
> > > And the strangest bit at the end: all you have to do to get rid of
> > such
> > > survivors
> > > is to open a window which has its own window manager (e.g. new
> > Workspace,
> > > Process
> > > Monitor, ...) and then invoke garbage collection...
> > >
> > > It seems that closed (debugger?) windows are somehow referenced by
> > their
> > > window
> > > manager, but we haven't found how, because when we inspect window
> > managers
> > > (WindowManager.ManagerRegistry), they are either empty or

> fix, the problem is now quite rare - which is great, but unfortunately
> means it's going to take longer to catch it.
>
> Cheers,
> Steve
>
> > -----Original Message-----
> > From: Terry Raymond [mailto:[hidden email]]
> > Sent: 12 May 2006 15:06
> > To: Steven Kelly
> > Subject: RE: Bad window management [VW7.4]
> >
> > Steve
> >
> > If you could send me a stack dump from one of these
> > WM processes I might be able to figure out what is going
> > on.
> >
> > If you use the attached fileIn, you can get a verbose dump
> > using the process monitor.
> >
> > Thanks.
> >
> > Terry
> >
> > ===========================================================
> > Terry Raymond       Smalltalk Professional Debug Package
> > Crafted Smalltalk
> > 80 Lazywood Ln.
> > Tiverton, RI  02878
> > (401) 624-4517      [hidden email]
> > <http://www.craftedsmalltalk.com>
> > ===========================================================
> > > -----Original Message-----
> > > From: Steven Kelly [mailto:[hidden email]]
> > > Sent: Friday, May 12, 2006 2:02 AM
> > > To: vwnc
> > > Subject: RE: Bad window management [VW7.4]
> > >
> > > Thanks Terry, good suggestion. For a second I thought you had it,
> since
> > > there are indeed some classes created on the fly and later

> > >
> > > Steve
> > >
> > > > -----Original Message-----
> > > > From: Terry Raymond [mailto:[hidden email]]
> > > > Sent: 11 May 2006 21:50
> > > > To: 'vwnc'
> > > > Subject: RE: Bad window management [VW7.4]
> > > >
> > > > Steve
> > > >
> > > > The only other way I can think of the reference path
> > > > collector not finding a path to an object is that the
> > > > path goes through an ObsoleteClass.
> > > >
> > > > Do you have any obsolete classes in your image? If so,
> > > > I suggest that you purge them out and then try your test
> > > > case.
> > > >
> > > > Terry
> > > >
> > > > ===========================================================
> > > > Terry Raymond       Smalltalk Professional Debug Package
> > > > Crafted Smalltalk
> > > > 80 Lazywood Ln.
> > > > Tiverton, RI  02878
> > > > (401) 624-4517      [hidden email]
> > > > <http://www.craftedsmalltalk.com>
> > > > ===========================================================
> > > >
> > > > > -----Original Message-----
> > > > > From: Steven Kelly [mailto:[hidden email]]
> > > > > Sent: Wednesday, May 10, 2006 12:37 PM
> > > > > To: vwnc
> > > > > Subject: RE: Bad window management [VW7.4]
> > > > >
> > > > > Try Terry's correction, posted here 27.4.06.
> > > > > http://www.parcplace.net/list/vwnc-archive/0604/msg00342.html
> > > > > (See Attachment link at the bottom of that page)
> > > > >
> > > > > We saw the same thing, and normally it was the #debugger key

> > > yet to
> > > > > find the smoking gun!
> > > > >
> > > > > Steve
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ladislav Lenart [mailto:[hidden email]]
> > > > > > Sent: 10 May 2006 19:18
> > > > > > To: vwnc
> > > > > > Subject: Bad window management [VW7.4]
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > we use WeakAnnouncements (only) and we encountered a strange
> > > behavior
> > > > > of
> > > > > > windows
> > > > > > as a side effect when running our tests.
> > > > > >
> > > > > > When we run all our tests which havily rely on announcements

> > > size).
> > > > > When
> > > > > > we do garbage collect afterwards, all these subscribers and
> their
> > > > > > subscription
> > > > > > registries are gc'ed.
> > > > > >
> > > > > > But when a test fails during a run and we terminate it, then
> some
> > > > > > subscriptions survive any
> > > > > > number of garbage collections.
> > > > > >
> > > > > > And the strangest bit at the end: all you have to do to get

> by
> > > > > their
> > > > > > window
> > > > > > manager, but we haven't found how, because when we inspect
> window
> > > > > managers
> > > > > > (WindowManager.ManagerRegistry), they are either empty or
> > > reference
> > > > > living
> > > > > > windows.
> > > > > >
> > > > > > BTW does anybody now why there is so many window managers

> -----Original Message-----
> From: Steven Kelly [mailto:[hidden email]]
> Sent: Friday, May 12, 2006 5:07 PM
> To: Terry Raymond
> Cc: vwnc
> Subject: RE: Bad window management [VW7.4]
>
> Terry,
>
> It may be finalization after all. I just spent 10 minutes on
> one set of
> objects. They were persistent class proxies, initially held
> on to by RB
> CodeModel through something funky in browsing class instance variable
> references (showed up as the only path in Inspect Reference
> Paths). That
> was fair enough, and I closed the RB in question, and the
> reference path
> went away - but the objects remained.
>
> I then spent about 5 minutes trying to go through with
> allOwnersWeakly:
> true from one of the objects. The owners were never meaningful. There
> was one WeakArray that holds on to these proxies, and the Trippy array
> for them, plus more Trippy stuff and arrays the more I searched. Every
> now and then I closed all inspectors and did a global gc, to no avail.
> Inspect Reference Paths was always empty, and the weak owners remained
> meaningless.
>
> I tried #purgeDeadWindows, but the only WM that was purged was a tool
> tip. The objects remained.
>
> I then spent another 5 minutes of no joy with
> allOwnersWeakly:, and then
> all of a sudden before my eyes the Trippy value in the slot I was
> looking at changed to zero, i.e. the object had been gc'd. All of the
> proxy objects had disappeared.
>
> I hadn't done anything different, so it looks like the finalization
> mechanism finally decided to kick in. For something at priority 98
> that's pretty lazy behavior :-), so there may be a problem somewhere.
>
> Steve
>
> > -----Original Message-----
> > From: Steven Kelly
> > Sent: 12 May 2006 15:41
> > To: 'Terry Raymond'
> > Subject: RE: Bad window management [VW7.4]
> >
> > Terry,
> >
> > Thanks. So far I've not caught a WindowManager Process that's
> connected to
> > the garbage objects. In fact, I've not found _anything_ that's
> connected
> > to those objects, other than a WeakArray holding them.
> Thanks to your
> WM
> > fix, the problem is now quite rare - which is great, but
> unfortunately
> > means it's going to take longer to catch it.
> >
> > Cheers,
> > Steve
> >
> > > -----Original Message-----
> > > From: Terry Raymond [mailto:[hidden email]]
> > > Sent: 12 May 2006 15:06
> > > To: Steven Kelly
> > > Subject: RE: Bad window management [VW7.4]
> > >
> > > Steve
> > >
> > > If you could send me a stack dump from one of these
> > > WM processes I might be able to figure out what is going
> > > on.
> > >
> > > If you use the attached fileIn, you can get a verbose dump
> > > using the process monitor.
> > >
> > > Thanks.
> > >
> > > Terry
> > >
> > > ===========================================================
> > > Terry Raymond       Smalltalk Professional Debug Package
> > > Crafted Smalltalk
> > > 80 Lazywood Ln.
> > > Tiverton, RI  02878
> > > (401) 624-4517      [hidden email]
> > > <http://www.craftedsmalltalk.com>
> > > ===========================================================
> > > > -----Original Message-----
> > > > From: Steven Kelly [mailto:[hidden email]]
> > > > Sent: Friday, May 12, 2006 2:02 AM
> > > > To: vwnc
> > > > Subject: RE: Bad window management [VW7.4]
> > > >
> > > > Thanks Terry, good suggestion. For a second I thought
> you had it,
> > since
> > > > there are indeed some classes created on the fly and later
> destroyed.
> > > > But that wouldn't explain why "WindowManager purgeDeadWindows"
> works.
> > > >
> > > > Steve
> > > >
> > > > > -----Original Message-----
> > > > > From: Terry Raymond [mailto:[hidden email]]
> > > > > Sent: 11 May 2006 21:50
> > > > > To: 'vwnc'
> > > > > Subject: RE: Bad window management [VW7.4]
> > > > >
> > > > > Steve
> > > > >
> > > > > The only other way I can think of the reference path
> > > > > collector not finding a path to an object is that the
> > > > > path goes through an ObsoleteClass.
> > > > >
> > > > > Do you have any obsolete classes in your image? If so,
> > > > > I suggest that you purge them out and then try your test
> > > > > case.
> > > > >
> > > > > Terry
> > > > >
> > > > > ===========================================================
> > > > > Terry Raymond       Smalltalk Professional Debug Package
> > > > > Crafted Smalltalk
> > > > > 80 Lazywood Ln.
> > > > > Tiverton, RI  02878
> > > > > (401) 624-4517      [hidden email]
> > > > > <http://www.craftedsmalltalk.com>
> > > > > ===========================================================
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Steven Kelly [mailto:[hidden email]]
> > > > > > Sent: Wednesday, May 10, 2006 12:37 PM
> > > > > > To: vwnc
> > > > > > Subject: RE: Bad window management [VW7.4]
> > > > > >
> > > > > > Try Terry's correction, posted here 27.4.06.
> > > > > >
> http://www.parcplace.net/list/vwnc-archive/0604/msg00342.html
> > > > > > (See Attachment link at the bottom of that page)
> > > > > >
> > > > > > We saw the same thing, and normally it was the #debugger key
> in
> > the
> > > > > > ProcessEnvironment of a debugger's WindowManager
> process that
> was
> > > > the
> > > > > > culprit. In those cases something really was hanging on to
> them,
> > and
> > > > the
> > > > > > fix corrects that.
> > > > > >
> > > > > > Even after that fix we still see a similar program
> with weakly
> > held
> > > > > > objects not being gc'd - or to be more accurate,
> Trippy's / AT
> > > > System
> > > > > > Analysis' Browse Reference Paths shows no reference paths to
> the
> > > > > > objects, but they are not gc'd. As you say, opening
> a Process
> > > > Monitor
> > > > > > clears things up; the shortest code to run to clear
> things up
> is:
> > > > > >
> > > > > > WindowManager purgeDeadWindows
> > > > > >
> > > > > > I've tried to find what holds these objects, and
> why doing the
> > above
> > > > > > helps, but couldn't so far. We've had this problem
> since 7.1;
> it
> > > > wasn't
> > > > > > in 3.0. My suspicion has been a problem in finalization, but
> I've
> > > > yet to
> > > > > > find the smoking gun!
> > > > > >
> > > > > > Steve
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ladislav Lenart [mailto:[hidden email]]
> > > > > > > Sent: 10 May 2006 19:18
> > > > > > > To: vwnc
> > > > > > > Subject: Bad window management [VW7.4]
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > we use WeakAnnouncements (only) and we
> encountered a strange
> > > > behavior
> > > > > > of
> > > > > > > windows
> > > > > > > as a side effect when running our tests.
> > > > > > >
> > > > > > > When we run all our tests which havily rely on
> announcements
> we
> > > > end up
> > > > > > > with
> > > > > > > several thousands subscribers
> (SubscriptionRegistry.Registries
> > > > size).
> > > > > > When
> > > > > > > we do garbage collect afterwards, all these
> subscribers and
> > their
> > > > > > > subscription
> > > > > > > registries are gc'ed.
> > > > > > >
> > > > > > > But when a test fails during a run and we
> terminate it, then
> > some
> > > > > > > subscriptions survive any
> > > > > > > number of garbage collections.
> > > > > > >
> > > > > > > And the strangest bit at the end: all you have to
> do to get
> rid
> > of
> > > > > > such
> > > > > > > survivors
> > > > > > > is to open a window which has its own window manager (e.g.
> new
> > > > > > Workspace,
> > > > > > > Process
> > > > > > > Monitor, ...) and then invoke garbage collection...
> > > > > > >
> > > > > > > It seems that closed (debugger?) windows are somehow
> referenced
> > by
> > > > > > their
> > > > > > > window
> > > > > > > manager, but we haven't found how, because when we inspect
> > window
> > > > > > managers
> > > > > > > (WindowManager.ManagerRegistry), they are either empty or
> > > > reference
> > > > > > living
> > > > > > > windows.
> > > > > > >
> > > > > > > BTW does anybody now why there is so many window managers
> each
> > > > with
> > > > > > one
> > > > > > > FlyByHelpWindow?
> > > > > > >
> > > > > > > Ladislav Lenart
>
>

> next clean image.
>
> Thomas
>
> > -----Original Message-----
> > From: Steven Kelly [mailto:[hidden email]]
> > Sent: Friday, May 12, 2006 5:07 PM
> > To: Terry Raymond
> > Cc: vwnc
> > Subject: RE: Bad window management [VW7.4]
> >
> > Terry,
> >
> > It may be finalization after all. I just spent 10 minutes on
> > one set of
> > objects. They were persistent class proxies, initially held
> > on to by RB
> > CodeModel through something funky in browsing class instance

> >
> > Steve
> >
> > > -----Original Message-----
> > > From: Steven Kelly
> > > Sent: 12 May 2006 15:41
> > > To: 'Terry Raymond'
> > > Subject: RE: Bad window management [VW7.4]
> > >
> > > Terry,
> > >
> > > Thanks. So far I've not caught a WindowManager Process that's
> > connected to
> > > the garbage objects. In fact, I've not found _anything_ that's
> > connected
> > > to those objects, other than a WeakArray holding them.
> > Thanks to your
> > WM
> > > fix, the problem is now quite rare - which is great, but
> > unfortunately
> > > means it's going to take longer to catch it.
> > >
> > > Cheers,
> > > Steve
> > >
> > > > -----Original Message-----
> > > > From: Terry Raymond [mailto:[hidden email]]
> > > > Sent: 12 May 2006 15:06
> > > > To: Steven Kelly
> > > > Subject: RE: Bad window management [VW7.4]
> > > >
> > > > Steve
> > > >
> > > > If you could send me a stack dump from one of these
> > > > WM processes I might be able to figure out what is going
> > > > on.
> > > >
> > > > If you use the attached fileIn, you can get a verbose dump
> > > > using the process monitor.
> > > >
> > > > Thanks.
> > > >
> > > > Terry
> > > >
> > > > ===========================================================
> > > > Terry Raymond       Smalltalk Professional Debug Package
> > > > Crafted Smalltalk
> > > > 80 Lazywood Ln.
> > > > Tiverton, RI  02878
> > > > (401) 624-4517      [hidden email]
> > > > <http://www.craftedsmalltalk.com>
> > > > ===========================================================
> > > > > -----Original Message-----
> > > > > From: Steven Kelly [mailto:[hidden email]]
> > > > > Sent: Friday, May 12, 2006 2:02 AM
> > > > > To: vwnc
> > > > > Subject: RE: Bad window management [VW7.4]
> > > > >
> > > > > Thanks Terry, good suggestion. For a second I thought
> > you had it,
> > > since
> > > > > there are indeed some classes created on the fly and later
> > destroyed.
> > > > > But that wouldn't explain why "WindowManager purgeDeadWindows"
> > works.
> > > > >
> > > > > Steve
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Terry Raymond [mailto:[hidden email]]
> > > > > > Sent: 11 May 2006 21:50
> > > > > > To: 'vwnc'
> > > > > > Subject: RE: Bad window management [VW7.4]
> > > > > >
> > > > > > Steve
> > > > > >
> > > > > > The only other way I can think of the reference path
> > > > > > collector not finding a path to an object is that the
> > > > > > path goes through an ObsoleteClass.
> > > > > >
> > > > > > Do you have any obsolete classes in your image? If so,
> > > > > > I suggest that you purge them out and then try your test
> > > > > > case.
> > > > > >
> > > > > > Terry
> > > > > >
> > > > > > ===========================================================
> > > > > > Terry Raymond       Smalltalk Professional Debug Package
> > > > > > Crafted Smalltalk
> > > > > > 80 Lazywood Ln.
> > > > > > Tiverton, RI  02878
> > > > > > (401) 624-4517      [hidden email]
> > > > > > <http://www.craftedsmalltalk.com>
> > > > > > ===========================================================
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Steven Kelly [mailto:[hidden email]]
> > > > > > > Sent: Wednesday, May 10, 2006 12:37 PM
> > > > > > > To: vwnc
> > > > > > > Subject: RE: Bad window management [VW7.4]
> > > > > > >
> > > > > > > Try Terry's correction, posted here 27.4.06.
> > > > > > >
> > http://www.parcplace.net/list/vwnc-archive/0604/msg00342.html
> > > > > > > (See Attachment link at the bottom of that page)
> > > > > > >
> > > > > > > We saw the same thing, and normally it was the #debugger

> > in
> > > the
> > > > > > > ProcessEnvironment of a debugger's WindowManager
> > process that
> > was
> > > > > the
> > > > > > > culprit. In those cases something really was hanging on to
> > them,
> > > and
> > > > > the
> > > > > > > fix corrects that.
> > > > > > >
> > > > > > > Even after that fix we still see a similar program
> > with weakly
> > > held
> > > > > > > objects not being gc'd - or to be more accurate,
> > Trippy's / AT
> > > > > System
> > > > > > > Analysis' Browse Reference Paths shows no reference paths

> > the
> > > > > > > objects, but they are not gc'd. As you say, opening
> > a Process
> > > > > Monitor
> > > > > > > clears things up; the shortest code to run to clear
> > things up
> > is:
> > > > > > >
> > > > > > > WindowManager purgeDeadWindows
> > > > > > >
> > > > > > > I've tried to find what holds these objects, and
> > why doing the
> > > above
> > > > > > > helps, but couldn't so far. We've had this problem
> > since 7.1;
> > it
> > > > > wasn't
> > > > > > > in 3.0. My suspicion has been a problem in finalization,

> > I've
> > > > > yet to
> > > > > > > find the smoking gun!
> > > > > > >
> > > > > > > Steve
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Ladislav Lenart [mailto:[hidden email]]
> > > > > > > > Sent: 10 May 2006 19:18
> > > > > > > > To: vwnc
> > > > > > > > Subject: Bad window management [VW7.4]
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > we use WeakAnnouncements (only) and we
> > encountered a strange
> > > > > behavior
> > > > > > > of
> > > > > > > > windows
> > > > > > > > as a side effect when running our tests.
> > > > > > > >
> > > > > > > > When we run all our tests which havily rely on
> > announcements
> > we
> > > > > end up
> > > > > > > > with
> > > > > > > > several thousands subscribers
> > (SubscriptionRegistry.Registries
> > > > > size).
> > > > > > > When
> > > > > > > > we do garbage collect afterwards, all these
> > subscribers and
> > > their
> > > > > > > > subscription
> > > > > > > > registries are gc'ed.
> > > > > > > >
> > > > > > > > But when a test fails during a run and we
> > terminate it, then
> > > some
> > > > > > > > subscriptions survive any
> > > > > > > > number of garbage collections.
> > > > > > > >
> > > > > > > > And the strangest bit at the end: all you have to
> > do to get
> > rid
> > > of
> > > > > > > such
> > > > > > > > survivors
> > > > > > > > is to open a window which has its own window manager

> > new
> > > > > > > Workspace,
> > > > > > > > Process
> > > > > > > > Monitor, ...) and then invoke garbage collection...
> > > > > > > >
> > > > > > > > It seems that closed (debugger?) windows are somehow
> > referenced
> > > by
> > > > > > > their
> > > > > > > > window
> > > > > > > > manager, but we haven't found how, because when we

> Good to hear I'm not alone - although of course I'm sorry to hear you
> have the problem. For the record, I've been finding the links to these
> same non-gc'd objects since 1993, by hand for the first 8 years or so.
> I've never been beaten yet - but since around 7.0 the behavior has been
> non-deterministic. After removing all links and gc'ing, the objects
> remain. Debugging and proceeding the finalization process, then gc'ing,
> has sorted the problem out every time I've tried it. Part of why that
> worked might be the WindowManager bug that Terry just fixed, but the
> circumstantial evidence of finalization's guilt is mounting :-).
>
> Steve
>
>> -----Original Message-----
>> From: Thomas Brodt [mailto:[hidden email]]
>> Sent: 12 May 2006 18:34
>> To: 'vwnc'
>> Subject: RE: Bad window management [VW7.4]
>>
>> Just to support you, I can tell same stories. Your report just
> describes
>> my
>> experiences, too.
>>
>> We have some image cleanup functionality (db sessions, ...). If
> something
>> remains, I can open an inspector on that. As you said, reference paths
>> never
>> worked for me, too, so I only used allOnwersWeakly, but mostly ended
> up
>> with
>> either WeakArrays which should clean up somewhen or references from
> Trippy
>> itself.
>> Cleaning up references by hand mostly never had any positive results
>> (although it should have) so I gave up somewhen and I never digged any
>> further. I just accepted that fact as mysterium and looked forward to
> the
>> next clean image.
>>
>> Thomas
>>
>>> -----Original Message-----
>>> From: Steven Kelly [mailto:[hidden email]]
>>> Sent: Friday, May 12, 2006 5:07 PM
>>> To: Terry Raymond
>>> Cc: vwnc
>>> Subject: RE: Bad window management [VW7.4]
>>>
>>> Terry,
>>>
>>> It may be finalization after all. I just spent 10 minutes on
>>> one set of
>>> objects. They were persistent class proxies, initially held
>>> on to by RB
>>> CodeModel through something funky in browsing class instance
> variable
>>> references (showed up as the only path in Inspect Reference
>>> Paths). That
>>> was fair enough, and I closed the RB in question, and the
>>> reference path
>>> went away - but the objects remained.
>>>
>>> I then spent about 5 minutes trying to go through with
>>> allOwnersWeakly:
>>> true from one of the objects. The owners were never meaningful.
> There
>>> was one WeakArray that holds on to these proxies, and the Trippy
> array
>>> for them, plus more Trippy stuff and arrays the more I searched.
> Every
>>> now and then I closed all inspectors and did a global gc, to no
> avail.
>>> Inspect Reference Paths was always empty, and the weak owners
> remained
>>> meaningless.
>>>
>>> I tried #purgeDeadWindows, but the only WM that was purged was a
> tool
>>> tip. The objects remained.
>>>
>>> I then spent another 5 minutes of no joy with
>>> allOwnersWeakly:, and then
>>> all of a sudden before my eyes the Trippy value in the slot I was
>>> looking at changed to zero, i.e. the object had been gc'd. All of
> the
>>> proxy objects had disappeared.
>>>
>>> I hadn't done anything different, so it looks like the finalization
>>> mechanism finally decided to kick in. For something at priority 98
>>> that's pretty lazy behavior :-), so there may be a problem
> somewhere.
>>>
>>> Steve
>>>
>>>> -----Original Message-----
>>>> From: Steven Kelly
>>>> Sent: 12 May 2006 15:41
>>>> To: 'Terry Raymond'
>>>> Subject: RE: Bad window management [VW7.4]
>>>>
>>>> Terry,
>>>>
>>>> Thanks. So far I've not caught a WindowManager Process that's
>>> connected to
>>>> the garbage objects. In fact, I've not found _anything_ that's
>>> connected
>>>> to those objects, other than a WeakArray holding them.
>>> Thanks to your
>>> WM
>>>> fix, the problem is now quite rare - which is great, but
>>> unfortunately
>>>> means it's going to take longer to catch it.
>>>>
>>>> Cheers,
>>>> Steve
>>>>
>>>>> -----Original Message-----
>>>>> From: Terry Raymond [mailto:[hidden email]]
>>>>> Sent: 12 May 2006 15:06
>>>>> To: Steven Kelly
>>>>> Subject: RE: Bad window management [VW7.4]
>>>>>
>>>>> Steve
>>>>>
>>>>> If you could send me a stack dump from one of these
>>>>> WM processes I might be able to figure out what is going
>>>>> on.
>>>>>
>>>>> If you use the attached fileIn, you can get a verbose dump
>>>>> using the process monitor.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Terry
>>>>>
>>>>> ===========================================================
>>>>> Terry Raymond       Smalltalk Professional Debug Package
>>>>> Crafted Smalltalk
>>>>> 80 Lazywood Ln.
>>>>> Tiverton, RI  02878
>>>>> (401) 624-4517      [hidden email]
>>>>> <http://www.craftedsmalltalk.com>
>>>>> ===========================================================
>>>>>> -----Original Message-----
>>>>>> From: Steven Kelly [mailto:[hidden email]]
>>>>>> Sent: Friday, May 12, 2006 2:02 AM
>>>>>> To: vwnc
>>>>>> Subject: RE: Bad window management [VW7.4]
>>>>>>
>>>>>> Thanks Terry, good suggestion. For a second I thought
>>> you had it,
>>>> since
>>>>>> there are indeed some classes created on the fly and later
>>> destroyed.
>>>>>> But that wouldn't explain why "WindowManager purgeDeadWindows"
>>> works.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Terry Raymond [mailto:[hidden email]]
>>>>>>> Sent: 11 May 2006 21:50
>>>>>>> To: 'vwnc'
>>>>>>> Subject: RE: Bad window management [VW7.4]
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> The only other way I can think of the reference path
>>>>>>> collector not finding a path to an object is that the
>>>>>>> path goes through an ObsoleteClass.
>>>>>>>
>>>>>>> Do you have any obsolete classes in your image? If so,
>>>>>>> I suggest that you purge them out and then try your test
>>>>>>> case.
>>>>>>>
>>>>>>> Terry
>>>>>>>
>>>>>>> ===========================================================
>>>>>>> Terry Raymond       Smalltalk Professional Debug Package
>>>>>>> Crafted Smalltalk
>>>>>>> 80 Lazywood Ln.
>>>>>>> Tiverton, RI  02878
>>>>>>> (401) 624-4517      [hidden email]
>>>>>>> <http://www.craftedsmalltalk.com>
>>>>>>> ===========================================================
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Steven Kelly [mailto:[hidden email]]
>>>>>>>> Sent: Wednesday, May 10, 2006 12:37 PM
>>>>>>>> To: vwnc
>>>>>>>> Subject: RE: Bad window management [VW7.4]
>>>>>>>>
>>>>>>>> Try Terry's correction, posted here 27.4.06.
>>>>>>>>
>>> http://www.parcplace.net/list/vwnc-archive/0604/msg00342.html
>>>>>>>> (See Attachment link at the bottom of that page)
>>>>>>>>
>>>>>>>> We saw the same thing, and normally it was the #debugger
> key
>>> in
>>>> the
>>>>>>>> ProcessEnvironment of a debugger's WindowManager
>>> process that
>>> was
>>>>>> the
>>>>>>>> culprit. In those cases something really was hanging on to
>>> them,
>>>> and
>>>>>> the
>>>>>>>> fix corrects that.
>>>>>>>>
>>>>>>>> Even after that fix we still see a similar program
>>> with weakly
>>>> held
>>>>>>>> objects not being gc'd - or to be more accurate,
>>> Trippy's / AT
>>>>>> System
>>>>>>>> Analysis' Browse Reference Paths shows no reference paths
> to
>>> the
>>>>>>>> objects, but they are not gc'd. As you say, opening
>>> a Process
>>>>>> Monitor
>>>>>>>> clears things up; the shortest code to run to clear
>>> things up
>>> is:
>>>>>>>>
>>>>>>>> WindowManager purgeDeadWindows
>>>>>>>>
>>>>>>>> I've tried to find what holds these objects, and
>>> why doing the
>>>> above
>>>>>>>> helps, but couldn't so far. We've had this problem
>>> since 7.1;
>>> it
>>>>>> wasn't
>>>>>>>> in 3.0. My suspicion has been a problem in finalization,
> but
>>> I've
>>>>>> yet to
>>>>>>>> find the smoking gun!
>>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Ladislav Lenart [mailto:[hidden email]]
>>>>>>>>> Sent: 10 May 2006 19:18
>>>>>>>>> To: vwnc
>>>>>>>>> Subject: Bad window management [VW7.4]
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> we use WeakAnnouncements (only) and we
>>> encountered a strange
>>>>>> behavior
>>>>>>>> of
>>>>>>>>> windows
>>>>>>>>> as a side effect when running our tests.
>>>>>>>>>
>>>>>>>>> When we run all our tests which havily rely on
>>> announcements
>>> we
>>>>>> end up
>>>>>>>>> with
>>>>>>>>> several thousands subscribers
>>> (SubscriptionRegistry.Registries
>>>>>> size).
>>>>>>>> When
>>>>>>>>> we do garbage collect afterwards, all these
>>> subscribers and
>>>> their
>>>>>>>>> subscription
>>>>>>>>> registries are gc'ed.
>>>>>>>>>
>>>>>>>>> But when a test fails during a run and we
>>> terminate it, then
>>>> some
>>>>>>>>> subscriptions survive any
>>>>>>>>> number of garbage collections.
>>>>>>>>>
>>>>>>>>> And the strangest bit at the end: all you have to
>>> do to get
>>> rid
>>>> of
>>>>>>>> such
>>>>>>>>> survivors
>>>>>>>>> is to open a window which has its own window manager
> (e.g.
>>> new
>>>>>>>> Workspace,
>>>>>>>>> Process
>>>>>>>>> Monitor, ...) and then invoke garbage collection...
>>>>>>>>>
>>>>>>>>> It seems that closed (debugger?) windows are somehow
>>> referenced
>>>> by
>>>>>>>> their
>>>>>>>>> window
>>>>>>>>> manager, but we haven't found how, because when we
> inspect
>>>> window
>>>>>>>> managers
>>>>>>>>> (WindowManager.ManagerRegistry), they are either empty
> or
>>>>>> reference
>>>>>>>> living
>>>>>>>>> windows.
>>>>>>>>>
>>>>>>>>> BTW does anybody now why there is so many window
> managers
>>> each
>>>>>> with
>>>>>>>> one
>>>>>>>>> FlyByHelpWindow?
>>>>>>>>>
>>>>>>>>> Ladislav Lenart
>>>
>>>
>
>