Removing #debugger from the process environment

> -----Original Message-----
> From: Steven Kelly [mailto:[hidden email]]
> Sent: Thursday, February 02, 2006 11:40 AM
> To: vwnc List
> Subject: Removing #debugger from the process environment
>
> What removes the #debugger->aDebuggerClient from the process
> environment? In 7.3.1 we've sometimes had problems when the debugger
> process has stayed around, and has kept hold of the debugger when that
> was closed (e.g. by clicking the X on the title bar). The debugger of
> course holds on to lots of stuff, so that can lead to large amounts of
> objects that don't get garbage collected, and are held by a rather
> obscure path.
>
> We added the following line to the end of DebuggerClient>>windowClosed
> self builder window windowProcess environmentAt: #debugger put:
> nil.
> and that seemed to help.
>
> Obviously, the issue here isn't the garbage (the process should be gc'd,
> which will sort out the DebuggerClient etc.), but the fact that
> DebuggerClient adds itself to the process environment in #postOpenWith:,
> but never cleans up after itself. Is a process permanently tainted by
> once having had a debugger in it? Although the process will normally be
> gc'd, is the above change more or less dangerous in cases where it
> isn't?
>
> Cheers,
> Steve

> I am a little confused here. The debugger client adds itself
> to the process environment of the debugger's ui process.
> Furthermore, the debugger window should be the only window
> controlled by the window manager of this ui process. So, I
> guess I would ask are there other windows running under the
> window manager used for the debugger client?
>
> > -----Original Message-----
> > From: Steven Kelly [mailto:[hidden email]]
> >
> > What removes the #debugger->aDebuggerClient from the process
> > environment? In 7.3.1 we've sometimes had problems when the
> debugger
> > process has stayed around, and has kept hold of the
> debugger when that
> > was closed (e.g. by clicking the X on the title bar). The
> debugger of
> > course holds on to lots of stuff, so that can lead to large
> amounts of
> > objects that don't get garbage collected, and are held by a rather
> > obscure path.
> >
> > We added the following line to the end of
> DebuggerClient>>windowClosed
> > self builder window windowProcess environmentAt:
> #debugger put: nil.
> > and that seemed to help.
> >
> > Obviously, the issue here isn't the garbage (the process should be
> > gc'd, which will sort out the DebuggerClient etc.), but the
> fact that
> > DebuggerClient adds itself to the process environment in
> > #postOpenWith:, but never cleans up after itself. Is a process
> > permanently tainted by once having had a debugger in it?
> Although the
> > process will normally be gc'd, is the above change more or less
> > dangerous in cases where it isn't?
> >
> > Cheers,
> > Steve
>
>

> -----Original Message-----
> From: Steven Kelly [mailto:[hidden email]]
> Sent: Thursday, February 02, 2006 12:30 PM
> To: vwnc List
> Subject: RE: Removing #debugger from the process environment
>
> Thanks for responding, Terry. I'd made that change a few months back,
> and I don't remember now what was hanging on to the Process. My guess
> too is that it was somehow via the WindowManager, although I can't see
> how. It happened more than once, though, but since the change it hasn't
> happened. In most cases the change isn't necessary, but it follows the
> good practice of windows cleaning up after themselves, and has been
> necessary in some rare cases, so I'll be keeping it if there's no way it
> can be dangerous.
>
> Interestingly enough, I have another similar change where someone from
> Cincom will probably say "no, that's unnecessary, the problem should
> never happen" - I'll post that separately. I feel correcting these is a
> good idea - rare, fully understood or not - providing they are not
> detrimental. There are too many places in VW where it's possible to get
> a UHE in some rare case in something central (event processing,
> debugger, system namespace relinking etc.), and some slightly more
> defensive programming in those areas might be a good idea.
>
> Thanks,
> Steve
>
> From: Terry Raymond [mailto:[hidden email]]
> > I am a little confused here. The debugger client adds itself
> > to the process environment of the debugger's ui process.
> > Furthermore, the debugger window should be the only window
> > controlled by the window manager of this ui process. So, I
> > guess I would ask are there other windows running under the
> > window manager used for the debugger client?
> >
> > > -----Original Message-----
> > > From: Steven Kelly [mailto:[hidden email]]
> > >
> > > What removes the #debugger->aDebuggerClient from the process
> > > environment? In 7.3.1 we've sometimes had problems when the
> > debugger
> > > process has stayed around, and has kept hold of the
> > debugger when that
> > > was closed (e.g. by clicking the X on the title bar). The
> > debugger of
> > > course holds on to lots of stuff, so that can lead to large
> > amounts of
> > > objects that don't get garbage collected, and are held by a rather
> > > obscure path.
> > >
> > > We added the following line to the end of
> > DebuggerClient>>windowClosed
> > > self builder window windowProcess environmentAt:
> > #debugger put: nil.
> > > and that seemed to help.
> > >
> > > Obviously, the issue here isn't the garbage (the process should be
> > > gc'd, which will sort out the DebuggerClient etc.), but the
> > fact that
> > > DebuggerClient adds itself to the process environment in
> > > #postOpenWith:, but never cleans up after itself. Is a process
> > > permanently tainted by once having had a debugger in it?
> > Although the
> > > process will normally be gc'd, is the above change more or less
> > > dangerous in cases where it isn't?
> > >
> > > Cheers,
> > > Steve
> >
> >

> -----Original Message-----
> From: Terry Raymond [mailto:[hidden email]]
> Sent: 02 February 2006 20:12
> To: Steven Kelly; 'vwnc List'
> Subject: RE: Removing #debugger from the process environment
>
>
> Steve
>
> Well, I guess it depends on your role. As a user of vw
> I sometimes just make a "fix" so I can proceed with my
> work. Other times I try to figure out why something that
> is not supposed to happen, did happen.
>
> In this case I would like to know how it happened because
> one of the things the debugger does is change the priority
> of the client ui process. This may not be a good thing to
> do if there is another window using the process.
>
> 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: Thursday, February 02, 2006 12:30 PM
> > To: vwnc List
> > Subject: RE: Removing #debugger from the process environment
> >
> > Thanks for responding, Terry. I'd made that change a few
> months back,
> > and I don't remember now what was hanging on to the
> Process. My guess
> > too is that it was somehow via the WindowManager, although
> I can't see
> > how. It happened more than once, though, but since the change it
> > hasn't happened. In most cases the change isn't necessary, but it
> > follows the good practice of windows cleaning up after
> themselves, and
> > has been necessary in some rare cases, so I'll be keeping it if
> > there's no way it can be dangerous.
> >
> > Interestingly enough, I have another similar change where
> someone from
> > Cincom will probably say "no, that's unnecessary, the
> problem should
> > never happen" - I'll post that separately. I feel
> correcting these is
> > a good idea - rare, fully understood or not - providing
> they are not
> > detrimental. There are too many places in VW where it's possible to
> > get a UHE in some rare case in something central (event processing,
> > debugger, system namespace relinking etc.), and some slightly more
> > defensive programming in those areas might be a good idea.
> >
> > Thanks,
> > Steve
> >
> > From: Terry Raymond [mailto:[hidden email]]
> > > I am a little confused here. The debugger client adds
> itself to the
> > > process environment of the debugger's ui process.
> Furthermore, the
> > > debugger window should be the only window controlled by
> the window
> > > manager of this ui process. So, I guess I would ask are
> there other
> > > windows running under the window manager used for the debugger
> > > client?
> > >
> > > > -----Original Message-----
> > > > From: Steven Kelly [mailto:[hidden email]]
> > > >
> > > > What removes the #debugger->aDebuggerClient from the process
> > > > environment? In 7.3.1 we've sometimes had problems when the
> > > debugger
> > > > process has stayed around, and has kept hold of the
> > > debugger when that
> > > > was closed (e.g. by clicking the X on the title bar). The
> > > debugger of
> > > > course holds on to lots of stuff, so that can lead to large
> > > amounts of
> > > > objects that don't get garbage collected, and are held
> by a rather
> > > > obscure path.
> > > >
> > > > We added the following line to the end of
> > > DebuggerClient>>windowClosed
> > > > self builder window windowProcess environmentAt:
> > > #debugger put: nil.
> > > > and that seemed to help.
> > > >
> > > > Obviously, the issue here isn't the garbage (the
> process should be
> > > > gc'd, which will sort out the DebuggerClient etc.), but the
> > > fact that
> > > > DebuggerClient adds itself to the process environment in
> > > > #postOpenWith:, but never cleans up after itself. Is a process
> > > > permanently tainted by once having had a debugger in it?
> > > Although the
> > > > process will normally be gc'd, is the above change more or less
> > > > dangerous in cases where it isn't?
> > > >
> > > > Cheers,
> > > > Steve
> > >
> > >
>
>