Removing #debugger from the process environment

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing #debugger from the process environment

Steven Kelly
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

Reply | Threaded
Open this post in threaded view
|

RE: Removing #debugger from the process environment

Terry Raymond
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?

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 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

Reply | Threaded
Open this post in threaded view
|

RE: Removing #debugger from the process environment

Steven Kelly
In reply to this post by Steven Kelly
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
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Removing #debugger from the process environment

Terry Raymond
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
> >
> >

Reply | Threaded
Open this post in threaded view
|

RE: Removing #debugger from the process environment

Steven Kelly
In reply to this post by Steven Kelly
Terry,

I'll turn the fix off and let you know if it happens again. If so, my
fix may need extending to correct not just the #debugger key but also
any other funky stuff the Debugger had done to the Process and
WindowManager (e.g. setting the priority high).

Thanks,
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
> > >
> > >
>
>