<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" 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;" dir="ltr">
<p>Hi all,</p>
<p><br>
</p>
<p>I took a closer look at the ActiveProcess concept and I think I found a solution approach to fix all these nasty infinite debugger chains that occurred when any bytecode simulation error occurred. Please see the attached changeset.</p>
<p><br>
</p>
<p>The main cognition was the issue that any bytecode simulation error, which is executed behind an #evaluate:onBehalfOf: call, should *not* be debugged on the "behalf-of" process but indeed on the "basic" active process who called #evaluate:onBehalfOf:. Otherwise,
the simulating process would not have been stopped by the debugger. See Process >> #step:, for example.</p>
<p>So I added Process >> #basicActiveProcess, which returns the real activeProcess without regard to #effectiveProcess. This method is used by StandardToolSet & debugger in order to identify the process to debug. At other places, #effectiveProcess must be never
used as this would take the idea of ActiveProcess ad absurdum and make it impossible to debug certain processing logic.</p>
<p>The changeset also consists of a new test method in DebuggerTests that tests this regression.</p>
<p><br>
</p>
<p>So this is a list of recent issues that *won't* crash your image after loading this changeset:</p>
<p></p>
<ul style="margin-bottom: 0px; margin-top: 0px;">
<li>
<div><a href="http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-nextPut-tp5108125p5109109.html" class="OWAAutoLink" previewremoved="true" id="LPlnk224626">http://forum.world.st/BUG-s-in-Context-control-jump-runUntilErrorOrReturnFrom-td5107263.html
(both scenarios)</a></div>
</li><li><a href="http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-nextPut-tp5108125p5109109.html" class="OWAAutoLink" id="LPlnk679751" previewremoved="true" style="font-size: 12pt;">http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-nextPut-tp5108125p5109109.html</a><br>
</li><li>
<div>Processor activeProcess</div>
<div>evaluate: [self error. self inform: #foo]</div>
<div>onBehalfOf: [] newProcess.</div>
</li><li>
<div>
<div>p := [| x |</div>
<div>[x := 5] value.</div>
<div>x] newProcess.</div>
<div>[p suspendedContext selector = thisContext selector]</div>
<div>whileFalse: [p step].</div>
<div>10 timesRepeat: [p step].</div>
<div>p suspendedContext pop.</div>
<div>p step<br>
"(I used this one to reproduce the situation fixed by <span>Kernel-ct.1296)"</span></div>
</div>
</li></ul>
<div><br>
</div>
<div>They still may raise a "usual" error because the context simulation is buggy in some respects, but so far I did not manage to find another bug that crashes your image. And this should make it so much easier to debug and fix the remaining simulation bugs!</div>
<div><br>
</div>
<div>In any case, please review! :-) I'm almost sure you will have some criticism, but how do you think about the approach in general? I wonder whether there will be any situation where we cannot debug the senders of #basicActiveProcess properly because they
don't follow the ActiveProcess concept. But in general, I think it's clearly an improvement against the current state of Trunk. I'm looking forward to your feedback!</div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
<br>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Thiede, Christoph<br>
<b>Gesendet:</b> Dienstag, 28. Januar 2020 09:17 Uhr<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Code simulation error (was Re: I broke the debugger?)</font>
<div> </div>
</div>
<div>
<div id="divtagdefaultwrapper" 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 id="divtagdefaultwrapper" 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">
<p>Hi Tim, excellent work!</p>
<p><br>
</p>
<p>Coincidentally, I studied the same problem yesterday, but I did not yet complete to report my observations to you. So let me to this hereby:</p>
<p><br>
</p>
<p>After many hours of funny debugging, now I could create this minimum failing example:</p>
<p><br>
</p>
<p></p>
</div>
<blockquote style="margin:0 0 0 40px; border:none; padding:0px">
<div 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>Processor activeProcess</div>
</div>
<div 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><span style="white-space:pre"></span>evaluate: [self error. self inform: #foo]</div>
</div>
<div 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><span style="white-space:pre"></span>onBehalfOf: [] newProcess</div>
</div>
</blockquote>
<div 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></div>
<br>
<p></p>
<p><b>Expected behavior:</b> First, a debugger is shown, and after proceeding it, a dialog window is shown.</p>
<p><b>Actual behavior:</b> Both the debugger and the dialog window are shown asynchronously!</p>
<p><b>Suspicion </b>of someone who did not yet dive deeply into the activeProcess concept: The debugger resumes the wrong process, as the activeProcess concept simulates a different running process for the error, even against the debugger.</p>
<p>If my theory is correct, we would need to find a way to look behind the scenes of the activeProcess and use it in the debugging code. But first, I really need to learn more about this concept.</p>
<p><br>
</p>
<p>(Connection to our Context >> #at: problems: Probably no primitive issue at all, just the fact, that #at: calls itself recursively after the error was proceeded - similar like #doesNotUnderstand: does.)</p>
<p><br>
</p>
<p>This is an in-midst-of-work message; just did not want us to any duplicate or redundant work. Will have a closer look at this disgusting problem ASAP!</p>
<p>And vice versa, it would be very nice if you could keep me/us up-to-date!</p>
<p><br>
</p>
<p>(Oh, what a fun to debug a self-simulating system ...)</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="Signature">
<div id="divtagdefaultwrapper" 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" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="_rp_T4" id="Item.MessagePartBody">
<div class="_rp_U4 ms-font-weight-regular ms-font-color-neutralDark rpHighlightAllClass rpHighlightBodyClass" id="Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
<br>
<br>
<div style="color:rgb(0,0,0)">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von tim Rowledge <tim@rowledge.org><br>
<b>Gesendet:</b> Dienstag, 28. Januar 2020 03:08 Uhr<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> [squeak-dev] Code simulation error (was Re: I broke the debugger?)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div class="PlainText">Something pretty weird is happening when the break is hit. I *finally* got a debugger open on a backtrace that includes the problem with Context>at: failing becasue the argument is 0. It's all a bit strange and unless I managed to do
something very odd it looks like a fairly serious bug.<br>
<br>
I actually caught this because something went wrong in code I added to try to log the dan initial error. Despite that it does appear to be a trace on the #break problem.<br>
<br>
<br>
debugger>doStep called from #stepOver.<br>
#handleLabelUpdatesIn:whenExecuting: used and does [interruptedProcess completeStep: currentContext] which uses...<br>
Process>>evaluate:onBehalfOf:<br>
Context>runUntilErrorOrReturnFrom:<br>
<br>
Context>jump<br>
- *we are checking for stackp = 0 which is the very thing that causes problems later with the #pop*<br>
<br>
In the #stepToSendOrReturn we use interpretNextInstructionFor: which leads to InterpretV3ClosuresExtension: 7 in: (Object>>break) for: ( aContext sender #on:do:, pc 24 stackp 0 method Object>>break, etc)<br>
-> doPop<br>
-> pop (presumably stackp was 0 here? See above re: #jump)<br>
-> at: ... but if so why did the error code appear to skip over the first two tests of it?<br>
<primitive: 210><br>
index = 0 ifTrue:[FileStream newFileNamed: 'squeakBreak.log' do:[:f| self errorReportOn: f]].<br>
index isInteger ifTrue:<br>
[self errorSubscriptBounds: index].<br>
index isNumber<br>
ifTrue: [^self at: index asInteger]"<--- it went here and on the second go around it picked up that index = 0 properly."<br>
ifFalse: [self errorNonIntegerIndex]<br>
<br>
<br>
So I *think* that there is an issue in Context>jump where we explicitly check for stackp = 0 but then call code that carefully does a pop via #at:. Something about the primitive: 210 (maybe?) does something weird and the index is both 0 and not 0 - nor even
an Integer.<br>
<br>
As an interesting bonus, the clause I added to log things when 'index = 0' went very wrong because the 'f' getting passed to the block is apparently the MultiByteFileStream *class* rather than the opened file!<br>
<br>
The bit bothering me at the moment is just how this can be a problem that hasn't whacked us before. I haven't been able to cause it with 'normal' code but all I was doing to fall over this was loading & testing the old Plumbing demo code.<br>
<br>
Oh, I did just try to see if a newer vm (I am running the 201912311458 ARMv6) would have a fix for the prim 210 but no newer ARM VM will run at all. The latest Mac vm runs but fails with the same huge list of notifiers reporting the error in Context>at: - the
fact that there is a *lot* of #at: on the stack is a little more odd.<br>
<br>
tim<br>
--<br>
tim Rowledge; tim@rowledge.org; <a href="http://www.rowledge.org/tim" id="LPlnk651199" previewremoved="true">
http://www.rowledge.org/tim</a><br>
Useful random insult:- If you stand close enough to him, you can hear the ocean<br>
<br>
<br>
<br>
</div>
</span></font></div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>