[Vm-dev] [VM-dev] Terminated process with zero pc

Eliot Miranda eliot.miranda at gmail.com
Wed May 13 00:44:21 UTC 2020


On Tue, May 5, 2020 at 1:12 PM Denis Kudriashov <dionisiydk at gmail.com>
wrote:

>
>
> вт, 5 мая 2020 г. в 20:52, Eliot Miranda <eliot.miranda at gmail.com>:
>
>>
>> Hi Denis,
>>
>> On May 5, 2020, at 12:39 PM, Denis Kudriashov <dionisiydk at gmail.com>
>> wrote:
>>
>> 
>> Hi.
>>
>> 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:
>>
>> ended := false.
>> process := [ Processor activeProcess suspend. ended := true]
>>                        forkAt: Processor activePriority + 1.
>> self assert: process isSuspended description: 'should be suspended'.
>>
>> process resume.
>>
>> self assert: ended description: 'last statement is done'.
>> self assert: process suspendedContext pc equals: 0
>>
>> When I try to run it locally the pc is always greater than #startpc.
>> 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). .
>>
>> In Pharo succeed process ends here:
>>
>> terminate
>>             ...........
>>
>>  self isActiveProcess ifTrue: [
>>
>> thisContext terminateTo: nil.
>>
>> self suspend ]
>>
>>
>> It seems that Context>>#terminateTo: can reset the pc to zero under some
>> condition (jitter related?).
>>
>>
>> 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.
>>
>
> And in that case Process>>terminate would be a jitted method context. In
> Pharo it is quite monstrous:
>
> https://github.com/pharo-project/pharo/blob/7fc0df20a60bfbdf06e7fa6f21cfdc9bba81c3cc/src/Kernel/Process.class.st#L679
>

SQUEAK IS NO BETTER.  THERE BE DRAGONS THERE.


>
> I will try to rerun my test with smaller refactored version.
>

That would be good to see.  please send any refactoring to us here in
squeakland; i'm sure we'd like to integrate it..

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200512/737ab645/attachment.html>


More information about the Vm-dev mailing list