<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 5 мая 2020 г. в 20:52, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="auto">Hi Denis,<div dir="ltr"><br><blockquote type="cite">On May 5, 2020, at 12:39 PM, Denis Kudriashov <<a href="mailto:dionisiydk@gmail.com" target="_blank">dionisiydk@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span><div dir="ltr">Hi.<div><br></div><div>I encounter interesting behavior of process termination. I can't reproduce it locally but I have constantly failing test on Pharo CI (as part of full test suite) due to following conditions:</div><div></div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>ended := false.</div><div>       process := [ Processor activeProcess suspend. ended := true] </div><div>                       forkAt: Processor activePriority + 1.</div><div>    self assert: process isSuspended description: 'should be suspended'.</div><div><br></div><div>    process resume.</div><div><br></div><div> self assert: ended description: 'last statement is done'.</div><div>        self assert: process suspendedContext pc equals: 0</div><div><br></div></blockquote><div>When I try to run it locally the pc is always greater than #startpc. </div><div>On CI the test very rarely behaves same way. The process is always finished (#ended is true) but in most of runs the pc of #terminate context is somehow reset to zero (probably related to the order of overall test suite). . </div><div><br></div><div>In Pharo succeed process ends here:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">terminate<br>            ...........</blockquote></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div> self isActiveProcess ifTrue: [</div></blockquote></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>                      thisContext terminateTo: nil.</div></blockquote></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>                       self suspend ]</div></blockquote></div></blockquote></blockquote><div><br></div><div>It seems that Context>>#terminateTo: can reset the pc to zero under some condition (jitter related?).</div></div></span></div></blockquote><div><br></div>The JIT maps machine code PCs to bytecode PCs whenever the pc is accessed of a context which is running JITted code.  If the mapping fails then 0 may be returned.  But this is evidence of a bug in the mapping computation.</div></blockquote><div><br></div><div>And in that case Process>>terminate would be a jitted method context. In Pharo it is quite monstrous: </div><div>      <a href="https://github.com/pharo-project/pharo/blob/7fc0df20a60bfbdf06e7fa6f21cfdc9bba81c3cc/src/Kernel/Process.class.st#L679">https://github.com/pharo-project/pharo/blob/7fc0df20a60bfbdf06e7fa6f21cfdc9bba81c3cc/src/Kernel/Process.class.st#L679</a><br></div><div>I will try to rerun my test with smaller refactored version.</div></div></div>