<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:#000000;font-family:Calibri,Helvetica,sans-serif;" 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 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 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">
<div>Processor activeProcess</div>
</div>
<div 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">
<div><span style="white-space:pre"></span>evaluate: [self error. self inform: #foo]</div>
</div>
<div 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">
<div><span style="white-space:pre"></span>onBehalfOf: [] newProcess</div>
</div>
</blockquote>
<div 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">
<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>
</body>
</html>