[squeak-dev] The Inbox: ToolBuilder-Morphic-ct.286.mcz

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Sun Jan 16 00:23:46 UTC 2022

Hi Jaromir,

as always, very nice observation! :) Yeah, I was already aware that stepping too early from this debugger before answering the dialog would lead to some weird behavior, but then I forgot about it again when I introduced this menu item a few years ago. Thanks for the reminder!

After taking a look in it, it's actually a pretty nice story that is going on here: If you press "debug invocation" and then immediately press any of the stepping buttons, then the new debugger will send the process which is displaying the dialog window a #complete: message with the displayed "suspended" context, which is not really the top context of this process (that would be MorphicDebugger class>>openOn:context:label:contents:fullView: - the debugger is often cutting away a few contexts from the top of the sender stack to keep it manageable for the user - to reproduce this, just open a halo on the "debug invocation" menu and debug its action invocation (debugging the debugger is so much fun!)) but rather, the debugger is pointing to the context that initially sent a message to the UIManager (in the bug report from below, this would be UndefinedObject>>DoIt). End of parentheses forest, during this stepping operation, the control is given back to the debuggee process via the #runUntilErrorOrReturnFrom: trick until it reaches the invocation context (#DoIt) again. So far so good, but in this case, it's actually taking a lot of time until this invocation context is reached again, because the dialog window will run in a large loop and do one world subcycle after each other until the dialog has been closed (see DialogWindow>>#offerDialogMenu). This means that everything you can see after pressing the stepping button for the first time is actually still happening INSIDE the stepping button, executed by the genuine process which was also responsible for showing up the debugger, so it is literally debugging itself, #runUntilErrorOrReturnFrom: has not yet returned. So if you pressed the stepping button for a second time, things would explode because the active process's suspendedContext is nil, thus the nil MNU for #findContextSuchThat:.

To cut a long story short, stepping from a "debug invocation" debugger before you answered the dialog is a bad thing and should not be done. But at the same time, I experienced the same confusion like you in the past as well, so I think it would be helpful to place a simple
	self inform: 'You must answer the dialog window before continuing stepping' translated.
right after the debugger invocation in DialogWindow>>#debugInvocation (a request to debug an active process will only return in the moment where this process is advanced). You can still stray off the desired path by resisting this call, but at least you will be warned now and know how to debug the dialog invocation properly.

I think this would be a good mitigation. If there is no objection from you or anyone else, I will patch this in a few days. Thank you for sweetening my evening with this interesting observation! :-)


Sent from Squeak Inbox Talk

On 2022-01-15T23:55:47+01:00, mail at jaromir.net wrote:

> Hi Christoph,
> I did steps 1 and 2 only and tried to step the debugger and was confused what happened next:
> - if you do step over twice the debugger gets "MessageNotUnderstood: UndefinedObject>>findContextSuchThat:" which is weird
> - however, if you do step through instead of step over, you even get an infinite loop, luckily recoverable via Alt+., which is even weirder...
> - and using step into instead of step over ends up with a similar MNU too.
> So maybe the pluggable dialog bug in your scenario has even deeper roots, I don't know... I don't understand why the MNU error above; I wouldn't expect that... it sounds like the debugger is searching for a context on the wrong stack...
> best,
> ~~~
> ^[^    Jaromir
> Sent from Squeak Inbox Talk
> On 2022-01-15T21:19:52+00:00, commits at source.squeak.org wrote:
> > A new version of ToolBuilder-Morphic was added to project The Inbox:
> > http://source.squeak.org/inbox/ToolBuilder-Morphic-ct.286.mcz
> > 
> > ==================== Summary ====================
> > 
> > Name: ToolBuilder-Morphic-ct.286
> > Author: ct
> > Time: 15 January 2022, 10:19:51.009373 pm
> > UUID: 3c0068e7-ce8e-5f45-8782-34c92bc6ab5f
> > Ancestors: ToolBuilder-Morphic-ct.285
> > 
> > Fixes a nil MNU when interrupting a pluggable dialog.
> > 
> > Steps to reproduce (before):
> >     1. Do it:
> >         Project uiManager chooseFrom: ((1 to: 10) collect: #asWords).
> >     2. Interrupt/Debug invocation
> >     3. Close/cancel the dialog
> >     4. Abandon the debugger
> > 
> > During the unwinding logic, the dialog window would attempt to close itself a second time, neglecting the fact that the model had already been released.
> > 
> > Inbox because only 90% sure that this is the right fix. :-)
> > 
> > =============== Diff against ToolBuilder-Morphic-ct.285 ===============
> > 
> > Item was changed:
> >   ----- Method: PluggableDialogWindow>>delete (in category 'submorphs - add/remove') -----
> >   delete
> >   
> > +     self model ifNil: [^ super delete].
> >       self model okToClose ifFalse: [^ self].
> >       
> >       self closeDialogSelector ifNotNil: [:sel | self model perform: sel].
> >       
> >       self model
> >           windowIsClosing;
> >           release.
> >       self model: nil.
> >       
> >       super delete.!
> > 
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220116/3f932abf/attachment.html>

More information about the Squeak-dev mailing list