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

[Denis Kudriashov]

Thanks Eliot.
That is interesting.

вт, 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.
>
> So I wonder what could be the explanation?
>
> I would like to understand this behavior before I will propose the change
> for Pharo (#isTerminate implementation needs to be fixed).
>
>
> There are exhaustive tests which test all pairs of mappable PCs map
> correctly in VMMaker.oscog.  Those tests could be run against all methods
> in Pharo.  The tests use in-image compilation to produce the JITted methods.
>
> But if there is a if such that either the tests are deficient or the VM is
> somehow suspending at a non-suspension point, the tests will not shoe the
> problem.
>
> I would work in trying to reproduce the problem, especially in an
> assert-enabled vm run on the command line.  Then you will see issues in the
> mapping algorithm well before the mapping algorithm fails and answers a
> zero pc.
>
>
> Best regards,
> Denis.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200505/c392b639/attachment.html>