<div dir="auto">Great explanation and great findings!<div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 11 mars 2021 à 19:52, Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>

<div id="m_-2333676420723652797divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>Thanks a lot for the collaboration, Marcel! :-)</p>
<p><br>
</p>
<p>> <span style="font-size:12pt">We basically figured out that the debugger that pops up from an unhandled error (or warning) must never try debugging a simulated process but always the "genuine process", which is the one that is actually running and which
 may do the code simulation for another process.</span></p>
<div><br>
</div>
<div><b>A small summary of this bug</b> for all interested readers who are not yet familiar with the debugging machinery: The actual issue causing all the debugger chains was a mechanism called
<b>process-faithful debugging.</b> In a nutshell, it makes sure that when you <b>
debug an expression such as "Process activeProcess",</b> the expression answers the correct process instance even when being debugged (that is, it must answer the
<i>process </i><i>being debugged</i> instead of the <i>debugger process</i> which is responsible for the debugging). Process-faithful debugging works by
<b>redirecting all sends to ProcessorScheduler </b><b>>> </b><b>#activeProcess to a so-called #effectiveProcess</b><b>.</b> However, when some error occurred in the debugging process during a debugging step (that is,
<b>a simulation error</b> such as [1] [2] occurred), a second debugger was opened - but because #activeProcess was just being subjected to redirection, this second debugger did not interrupt the
<i>debugging process</i> but the <i>process being debugged</i> instead. As a consequence,
<b>the faulty debugging process kept running</b> and was given the opportunity to do any other harm. If you now take a look into how Object >> #at: or Object >> #doesNotUnderstand: are implemented (that is, by
<b>unlimited recursion</b>), you will see that <b>it could fire one debugger after the next one</b> this way, without limitation, causing the infinite debugger chains that broke your images.</div>
<div><br>
</div>
<div><b>The solution,</b> in its simplest form, was pretty straightforward: <b>When opening a debugger from an error</b> (see StandardToolSet >> #handleError: and others), make sure
<b>not to honor process-faithful debugging</b> but always open the debugger on the actually running process, which we decided to call
<i>genuineProcess</i> for sake of differentiation from #activeProcess. The rest of the changeset focuses on some
<b>additional refactoring of the overall debugging API</b> on Process and ProcessorScheduler, striving to make it more intuitive for application developers to choose the right process and context for debugging.</div>
<div><br>
</div>
<div>If you want to learn even more details, the first thread provided by Marcel should be quite interesting (though also quite long). Otherwise, we'll be here for your questions. :-)</div>
<div><br>
</div>
<div>What an interesting project this has been! I'm already looking forward to the next one! :-)</div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
<div><br>
</div>
<div>[1] <a href="http://forum.world.st/The-Trunk-Kernel-ct-1357-mcz-td5124373.html" id="m_-2333676420723652797LPlnk718562" target="_blank" rel="noreferrer">http://forum.world.st/The-Trunk-Kernel-ct-1357-mcz-td5124373.html</a></div>
<div>[2] <a href="http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-nextPut-tp5108125.html" id="m_-2333676420723652797LPlnk730317" target="_blank" rel="noreferrer">http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-nextPut-tp5108125.html</a></div>
<p></p>
<div id="m_-2333676420723652797Signature">
<div id="m_-2333676420723652797divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_-2333676420723652797divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank" rel="noreferrer">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Taeumel, Marcel<br>
<b>Gesendet:</b> Donnerstag, 11. März 2021 18:01:55<br>
<b>An:</b> squeak-dev<br>
<b>Betreff:</b> [squeak-dev] Please try out | Fixes for debugger invocation during code simulation</font>
<div> </div>
</div>
<div>
<div id="m_-2333676420723652797__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:#000000;text-align:left" dir="ltr">
Hi all!
<div><br>
</div>
<div>Christoph put in a lot of effort to figure out the cause of infinite debugger chains under various circumstances. He is curious how far "debugging the debugger" can work and how possible improvements to code simulation might look like.</div>
<div><br>
</div>
<div>We basically figured out that the debugger that pops up from an unhandled error (or warning) must never try debugging a simulated process but always the "genuine process", which is the one that is actually running and which may do the code simulation for
 another process.</div>
<div><br>
</div>
<div>Please find attached a change set with that fix. Tests are in "DebuggerTests" and "ProcessTest".
<b>The most interesting methods are ProcessorScheduler >> #debugContext:title:full:contents: and Process >> #debugWithTitle:full:contents:.
</b>Please take a look at their comments.<br>
<div></div>
<div><br>
</div>
<div>We will merge this into Trunk in a some days, given that there are no objections. :-)</div>
<div><br>
</div>
<div>Related discussions:</div>
<div><a href="http://forum.world.st/I-broke-the-debugger-tp5110752p5110814.html" target="_blank" rel="noreferrer"><span style="font-size:10pt">http://forum.world.st/I-broke-the-debugger-tp5110752p5110814.html</span></a><br>
</div>
<div><span style="font-size:10pt"><a href="http://forum.world.st/The-Inbox-Morphic-ct-1610-mcz-tp5108228.html" target="_blank" rel="noreferrer">http://forum.world.st/The-Inbox-Morphic-ct-1610-mcz-tp5108228.html</a></span><br>
</div>
</div>
<div><br>
</div>
<div>Best,</div>
<div>Marcel and Christoph</div>
<div><br>
</div>
<div>P.S.: Debugging a dialog invocation looks nicer now. Try it out.</div>
<div><img id="m_-233367642072365279733b04c9d-c2c9-4792-8454-1615998ebf8a" width="283" height="78" src="cid:88c0dc63-3136-44f8-9b3a-fd5e947e85be"><br>
</div>
</div>
</div>
</div>

<br>
</blockquote></div>