> I don't know whether this will ever come to an end.


I'm almost sure it won't. This must be kind of a recursive error.

Afaik each debugger does a few hidden steps before appearing to the user (to hide the implementation details of UnhandledError; if the debugger opens, you will land at the outerContext or so), and I think somewhere on this way, an invalid context (with a nil sender) is passed ... But I could not investigate it yet.

If you would like to do so, you could experiment with inserting an #inform: in #handleError: and then open the ProcessBrowser before the next debugger appears.


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob at resfarm.de>
Gesendet: Montag, 30. Dezember 2019 14:07:53
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)

Encountered it again today. This time while stepping over something it ran into a self break, but instead of interrupting, the image froze until I pressed Cmd+. Now I get countless debuggers on the self break frame plus many more countless debuggers on Context>>cannotReturn:to: with a BlockCannotReturn exception.

It only hang for about 10 seconds and is still spawning debuggers after half an hour... I don't know whether this will ever come to an end.

--- The full stack ---
[] in DosFileDirectory(FileDirectory)>>deleteFileNamed:ifAbsent:
StandardFileStream class>>retryWithGC:until:forFileNamed:
DosFileDirectory(FileDirectory)>>deleteFileNamed:ifAbsent:
SmalltalkImage>>logError:inContext:to:
SmalltalkImage>>logSqueakError:inContext:
[] in Debugger class>>openOn:context:label:contents:fullView:
BlockClosure>>on:do:
Debugger class>>openOn:context:label:contents:fullView:
ECToolSet class(StandardToolSet class)>>debugProcess:context:label:contents:fullView:
ToolSet class>>debugProcess:context:label:contents:fullView:
Process>>debug:title:full:contents:
Process>>debug:title:full:
Process>>debug:title:
ECToolSet class(StandardToolSet class)>>handleError:
ToolSet class>>handleError:
UnhandledError>>defaultAction
UndefinedObject>>handleSignal:
UnhandledError(Exception)>>signal
UnhandledError class>>signalForException:
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BlockCannotReturn(Error)>>defaultAction
BlockCannotReturn>>defaultAction
UndefinedObject>>handleSignal:
BlockCannotReturn(Exception)>>signal
Context>>cannotReturn:to:
Context>>cannotReturn:
[] in BlockClosure>>newProcess

Am Mo., 23. Dez. 2019 um 20:05 Uhr schrieb Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>>:

Hi Jakob,


yes, these observations are very well known to me ... :)

> Is there a way to stop this if it happens? I have "Open tools attached to hand" activated so I cannot click on Do > Utilities closeAllDebuggers...

FYI, you can also press Ctrl + 5 to open the "Do" menu and then type "De" + Enter to perform "Utilities closeAllDebuggers".
Or modify Marcel's changeset from May (cmd-dot-dialog.cs) and add the command there :)

However, we should sharpen our error detection while opening a debugger. This would make it so much easier to debug such problems ...

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> im Auftrag von Jakob Reschke <forums.jakob at resfarm.de<mailto:forums.jakob at resfarm.de>>
Gesendet: Montag, 23. Dezember 2019 17:55:38
An: The general-purpose Squeak developers list
Betreff: [squeak-dev] Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)

Am Mo., 16. Dez. 2019 um 14:32 Uhr schrieb Marcel Taeumel <marcel.taeumel at hpi.de<mailto:marcel.taeumel at hpi.de>>:
Hi Christoph,

hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:

1. Generator step-over
Generator on: [:g | g yield: #foo].

2. Error in a debugger's build-with method.

Best,
Marcel

FYI today there are still some cases that spawn endless debuggers.

It had it twice today, but unfortunately can't give you exacts steps for reproduction.
1. Debug a test case, step over some long operation, interrupt with Cmd+. to because of impatience, step so far in the second debugger that control could theoretically return to the first one. Then there was some Context on the top of the stack that did not seem to belong there, with a return handler... Well I had a manual ping-pong situation between the two debuggers. After pressing the wrong button it resulted in an endless stream of new debuggers about not being able to return.
2. Press Into at the wrong place during a return handler (ensure:). Endless debuggers about aboutToReturn:through: (I saw that somewhere). The stack trace shows back-and-forth between Message>>sentTo: and UndefinedObject doesNotUnderStand: #findContextSuchThat: -- see attachment.

Maybe I should finally start to remember taking screenshots. Both cases seemed to be related to stack unwinding or ensure: actions though.

Is there a way to stop this if it happens? I have "Open tools attached to hand" activated so I cannot click on Do > Utilities closeAllDebuggers...

Merry Christmas everyone.
Kind regards,
Jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191230/a941762f/attachment.html>