Occasional disabled windows after debugger is killed ?

Since beta4 I've seen an occasional problem where killing a debugger didn't
re-enable the window from which it was started.  I've seen it both with
F11-ing from a workspace and from a "self halt" in a different app.

I can't make it reproduce to order.  In fact It's only happened a very few
times, and I haven't been able to find anything obviously wrong when it did.
There were no zombie debuggers hanging around, for one thing.

I know this isn't much help as bug reports go, but I wondered whether anyone
else has seen the same thing at all.  If not, then it's probably not worth
bothering about.

    -- chris

Chris,

> Since beta4 I've seen an occasional problem where killing a debugger
didn't
> re-enable the window from which it was started.  I've seen it both with
> F11-ing from a workspace and from a "self halt" in a different app.
>
> I can't make it reproduce to order.  In fact It's only happened a very few
> times, and I haven't been able to find anything obviously wrong when it
did.
> There were no zombie debuggers hanging around, for one thing.
>
> I know this isn't much help as bug reports go, but I wondered whether
anyone
> else has seen the same thing at all.  If not, then it's probably not worth
> bothering about.

I encountered the disabled window part, but it came back after I closed the
debugger.  Scandelous as it might sound in this SUnit age<g>, I evaluated
some smoke test code from a method comment, spotted the error in the
debugger and found that I was unable to activate the browser with the
debugger open.  I mention it only because it might help you reproduce your
problem???

Which OS are you using?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Since beta4 I've seen an occasional problem where killing a debugger
didn't
> re-enable the window from which it was started.  I've seen it both with
> F11-ing from a workspace and from a "self halt" in a different app.
>
> I can't make it reproduce to order.  In fact It's only happened a very few
> times, and I haven't been able to find anything obviously wrong when it
did.
> There were no zombie debuggers hanging around, for one thing.
>
> I know this isn't much help as bug reports go, but I wondered whether
anyone
> else has seen the same thing at all.  If not, then it's probably not worth
> bothering about.

This is a possible side-effect of the new behaviour whereby shells are
disabled for the duration of execution of commands (thus preventing any
possibility of another command being fired until it completes, even if
further dialogs or message boxes are opened to complete the command). The
re-enablement is guaranteed by a #ensure: block, but that will only run when
the stack unwinds past that point. This will happen eventually, but as
Dolphin is running multiple Smalltalk threads on a single operating system
thread (and therefore a single OS stack), and is handling Windows' events in
a "proper" synchronous manner, it is possible for one Smalltalk process to
block another from returning until it itself has exited from a later
callback. Here is a scenario:

1) One opens debugger 1 from inside a Windows' event handler (which will
almost always be the case when debugging the UI process)
2) One opens debugger 2 from inside another Windows' event handler. Note
that the callback which resulted in the first debugger being opened has
still not returned.
3) Now close debugger 1. The process which Debugger 1 was debugging is
blocked from unwinnding, because there is a later callback on the native
thread stack which has not yet returned. In order to avoid corrupting the
stack, the debugged process must wait until the later callback has returned
before it can continue winding up.

This is one example of why the ensure block might not run immediately when
one closes the debugger, and consequently the "debugged" window could remain
disabled.

A useful tip is to use the Visual Object Finder to open an inspector on the
disabled view, and then use the PAI to toggle its #isEnabled aspect back to
true.

Regards

Blair

Blair,

> This is a possible side-effect of the new behaviour whereby shells are
> disabled for the duration of execution of commands (thus preventing any
> possibility of another command being fired until it completes, even if
> further dialogs or message boxes are opened to complete the command). The
> re-enablement is guaranteed by a #ensure: block, but that will only run
when
> the stack unwinds past that point. This will happen eventually, but as
> Dolphin is running multiple Smalltalk threads on a single operating system
> thread (and therefore a single OS stack), and is handling Windows' events
in
> a "proper" synchronous manner, it is possible for one Smalltalk process to
> block another from returning until it itself has exited from a later
> callback. Here is a scenario:

Can that kind of scenario arise without:

    Debugger>>allInstances

answering a non-empty collection ?   I did check that (on one occasion), and
there were no debuggers left alive.

I'll keep an eye out for it happening again, but since no one else has
mentioned seeing the problem, it can probably be safely ignored.

> Blair

    -- chris

Bill,

> I mention it only because it might help you reproduce your
> problem???

Thanks, Bill, but the intermittent problem is about the View staying disable
*after* the debugger has gone away.

> Bill

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > This is a possible side-effect of the new behaviour whereby shells are
> > disabled for the duration of execution of commands (thus preventing any
> > possibility of another command being fired until it completes, even if
> > further dialogs or message boxes are opened to complete the command).
The
> > re-enablement is guaranteed by a #ensure: block, but that will only run
> when
> > the stack unwinds past that point. This will happen eventually, but as
> > Dolphin is running multiple Smalltalk threads on a single operating
system
> > thread (and therefore a single OS stack), and is handling Windows'
events
> in
> > a "proper" synchronous manner, it is possible for one Smalltalk process
to
> > block another from returning until it itself has exited from a later
> > callback. Here is a scenario:
>
> Can that kind of scenario arise without:
>
>     Debugger>>allInstances
>
> answering a non-empty collection ?   I did check that (on one occasion),
and
> there were no debuggers left alive.

Yes. The Debugger may have disconnected from the process, but that does not
necessarily mean that the process has successfully terminated yet. You'd
need to check the process monitor to see. Since the #ensure: blocks will
definitely run (unless the process is actively #kill'd, which just finishes
it off in a much more dangerous way), and the View is definitely re-enabled
by an ensure block, then one can only conclude that either the process has
not terminated (causing the ensure block to run), or that something else has
disabled the view subsequently. The former seems more likely.

Regards

Blair

Blair,

> Yes. The Debugger may have disconnected from the process, but that does
not
> necessarily mean that the process has successfully terminated yet. You'd
> need to check the process monitor to see. Since the #ensure: blocks will
> definitely run (unless the process is actively #kill'd, which just
finishes
> it off in a much more dangerous way), and the View is definitely
re-enabled
> by an ensure block, then one can only conclude that either the process has
> not terminated (causing the ensure block to run), or that something else
has
> disabled the view subsequently. The former seems more likely.

Thanks,  I'll check that if it ever happens again. (I bet it doesn't).

> Blair

    -- chris