Infinite series of debuggers opening

There was some talk on another VW list about the decision in VW not to
separate the IDE from the "hosted program" - your app. Obviously in many
cases that's a strong point of VW, but in that discussion the problem
was that a dialog opened by the hosted program also blocked the whole
IDE. Pressing Ctrl+Y to open a debugger, and thus turning off the modal
nature of the dialog, is something of a workaround, but not ideal.

Another related area where IDE and "hosted program" separation could be
improved is the debugger. Currently trying to debug anything to do with
base widget display or event handling leads to opening a
near-unstoppable series of debuggers, since the very act of opening the
debugger triggers the same code where your halt or breakpoint is. There
are of course ways around this:

- make the breakpoint only work once, using a Debug Variable and
condition:
  - Debug | Inspect Debug Variables | Add... ( #Once with value 0)
  - condition: DebugActive and: [(Once := Once + 1) <= 1]

What would be nice though is if the system could offer a little help.
Something along the lines of the Debugger noticing when its opening
itself whilst executing its own opening code, or just when its opening
its 50th instance. It could turn off debugging and tell the user how to
turn it back on again, in case someone really wanted 51 debuggers.

The EmergencyWindow could also be made to stop all other damage and
event processing while it is open. And the following has proved useful
on several occasions:

- Add the following to #emergencyHelpString in  EmergencyWindow
  - PDPManager toggleDebugging "i.e. Debug | Disable Probes"
  - RefactoryChangeManager instance undoOperation. "Undoes the last
change"

Does anyone else have any tips about avoiding the "infinite debuggers"
scenario?

Cheers,
Steve

Fortunately, this is very easy:
Settings>>Tools>>Debugger>>Use event faithful debugging -> true

This is almost always on in my images, since I do a lot with the GUI :-)

Cheers,
        Christian

Yes, I always use event faithful debugging. Unfortunately, that doesn't help at all in this case, since the problem is that opening the Debugger causes the error again, which opens another Debugger...

Steve

Steve

Off the top of my head, I could probably add a debugger
count and turn off probes when that count has been reached.
However, that really may not completely solve the problem
if a bug is introduced into the wrong part of the system.

I would introduce a new setting that would only allow N
instances of the debugger service in the system. If the limit
is reached I would turn off DebugActive or just refuse to
open more debuggers. But now we need to define an action
to be taken if an unhandled exception occurs and the debugger
should not be opened. How about dump and hard terminate 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>
===========================================================

Terry Raymond wrote:
Thanks Terry. I'd suggest sticking with turning off DebugActive as the
first line of attack. Most of the time that would stop the problem -
there is no error in the system, so you can continue to work. [BTW I
notice that in some cases the default probe condition is ^DebugActive,
but in others it is empty (adding a conditional probe?). I'd suggest
moving DebugActive out of the visible conditions altogether, and making
the conditional test be always dependent on it.]

If the user has introduced an error in the system, turning off
DebugActive won't help - in the worst cases each MouseMovedEvent (or
even any event) causes a new debugger. Still, most of the time undoing
the last RB action will help even then, so maybe we could try that. We'd
obviously want to tell the user what we had done. We couldn't confirm it
beforehand, since in these cases even opening a confirm Dialog is enough
to re-trigger the error.

Of course neither of these is watertight, and both have their loopholes
and downsides, but they'd still be a big improvement. If neither of them
work, we're kind of stuck. Dumping is certainly a good idea. Hard
terminating the process (presumably just one Smalltalk lightweight
Process) may not help - doesn't WindowManager generate another one?
Maybe we could freeze the process, like Process Monitor does? I wouldn't
worry too much about this though - we've already coped with the vast
majority of cases, and there'll always be some that slip through our
net.

Steve

> > -----Original Message-----
> > From: Steven Kelly [mailto:[hidden email]]
> > Sent: Monday, July 31, 2006 4:08 AM
> > To: VW NC
> > Subject: Infinite series of debuggers opening
> >
> > There was some talk on another VW list about the decision in VW not
to
> > separate the IDE from the "hosted program" - your app. Obviously in
many
> > cases that's a strong point of VW, but in that discussion the
problem
> > was that a dialog opened by the hosted program also blocked the
whole
> > IDE. Pressing Ctrl+Y to open a debugger, and thus turning off the
modal
> > nature of the dialog, is something of a workaround, but not ideal.
> >
> > Another related area where IDE and "hosted program" separation could
be
> > improved is the debugger. Currently trying to debug anything to do
with
> > base widget display or event handling leads to opening a
> > near-unstoppable series of debuggers, since the very act of opening
the
> > debugger triggers the same code where your halt or breakpoint is.
There
> > are of course ways around this:
> >
> > - make the breakpoint only work once, using a Debug Variable and
> > condition:
> >   - Debug | Inspect Debug Variables | Add... ( #Once with value 0)
> >   - condition: DebugActive and: [(Once := Once + 1) <= 1]
> >
> > What would be nice though is if the system could offer a little
help.
> > Something along the lines of the Debugger noticing when its opening
> > itself whilst executing its own opening code, or just when its
opening
> > its 50th instance. It could turn off debugging and tell the user how
to
> > turn it back on again, in case someone really wanted 51 debuggers.
> >
> > The EmergencyWindow could also be made to stop all other damage and
> > event processing while it is open. And the following has proved
useful
> > on several occasions:
> >
> > - Add the following to #emergencyHelpString in  EmergencyWindow
> >   - PDPManager toggleDebugging "i.e. Debug | Disable Probes"
> >   - RefactoryChangeManager instance undoOperation. "Undoes the last
> > change"
> >
> > Does anyone else have any tips about avoiding the "infinite
debuggers"
> > scenario?
> >
> > Cheers,
> > Steve

DebugActive is visble because breakpoint probes can be used for
non-breakpoint purposes and in those cases you don't want them to
be sensitive to DebugActive. That is why when you indicate you want
to have a conditional probe the default expression is ^false instead
of ^DebugActive.

Yep, pausing the process may be a better idea.

In addition to using the Emergency Evaluator, one can hit ctrl-\ which will
pause all user processes and open the Process Monitor. This is usually
effective at stopping the infinite debugger loop. But, now there is the
problem of closing all those exception and debugger windows and killing
the processes. I think it would help to have a few commands in the
process monitor to assist in this. I think the process monitor can be
rather helpful in regaining control of runaway processes and zombie
windows.

Terry
 
===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

---

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm