modifying copied context vars

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

modifying copied context vars

Nicolai Hess-3-2
Hello,

we have a failing test (OCClosureCompilerTest>>#testDebuggerTempAccess)
(fails since spur, but not related - I think).

A simple example to reproduce the behavior:
| local1 remote1|
remote1:=4.
local1 :=3.
[:i | |c|
    c := local1.
    remote1 := i.
    i halt.
    "local1:=25.  <-- evaluate during debugging"
     ] value:1.
Transcript show:local1;cr.
Transcript show:remote1;cr
.
(Executing this code and evaluating "local:=25" after the debugger halts for
"i halt" will modify the var "remote1" instead of "local1", as this is a vector tempvar , proceeding
the execution will crash at accessing the remote1 value).


The purpose of the testDebuggerTempAccess test case is, evaluating code
that changes the value of a copied temp var *does not* change the value of
this var in the outer context. (see comment in the test case:
"this is not 25 as the var is a local, non escaping variable that was copied into the block,
    If the compiler would have known about the write, it would have made the var escaping".
)

But the implementation (OCCopyingTempVariable>>#writeFromContext: aContext scope: contextScope value: aValue)
explicitly iterates through all outer context(s) and changes the vars as well.

1. Question: Who is right?

But the reason why the test actually fails is different. It is because evaluating
the code that modifies the var "local1:=25" ends up to a call
aContext tempAt: self indexFromIR put: aValue
but the index (indexFromIR) can be different for every context (method context / inner block
context(s)).

2. Question: should the index be always the same?

thanks inadvance

Nicolai


ps: since spur (resp. compiler changes that were done for new spur images), the index of tempvars can be different.
In pre-spur, this testcase modifies an outer context var, but one that isn't checked (the argument "two"), therefore
the test succeed. In spur, this testcase modifes a different outer context var "remote1", and the test
fails.
Reply | Threaded
Open this post in threaded view
|

Re: modifying copied context vars

Henrik Nergaard

Not only is the test failing, but if you modify line 13 from “(1 to: 2) do: “  to  “(1 to: 1) do:”  in #doTestDebuggerTempAccessWith:with: then Pharo will crash post spur, while pre spur the last assertion will fail.

 

Best regards,

Henrik

 

From: Pharo-dev [mailto:[hidden email]] On Behalf Of Nicolai Hess
Sent: Thursday, March 24, 2016 9:53 AM
To: Pharo Development List <[hidden email]>; The general-purpose Squeak developers list <[hidden email]>
Subject: [Pharo-dev] modifying copied context vars

 

Hello,

we have a failing test (OCClosureCompilerTest>>#testDebuggerTempAccess)
(fails since spur, but not related - I think).

A simple example to reproduce the behavior:

| local1 remote1|
remote1:=4.
local1 :=3.
[:i | |c|
    c := local1.
    remote1 := i.
    i halt.
    "local1:=25.  <-- evaluate during debugging"
     ] value:1.
Transcript show:local1;cr.
Transcript show:remote1;cr.

(Executing this code and evaluating "local:=25" after the debugger halts for

"i halt" will modify the var "remote1" instead of "local1", as this is a vector tempvar , proceeding

the execution will crash at accessing the remote1 value).

 

 

The purpose of the testDebuggerTempAccess test case is, evaluating code

that changes the value of a copied temp var *does not* change the value of

this var in the outer context. (see comment in the test case:
"this is not 25 as the var is a local, non escaping variable that was copied into the block,
    If the compiler would have known about the write, it would have made the var escaping".
)

But the implementation (OCCopyingTempVariable>>#writeFromContext: aContext scope: contextScope value: aValue)

explicitly iterates through all outer context(s) and changes the vars as well.

1. Question: Who is right?

But the reason why the test actually fails is different. It is because evaluating

the code that modifies the var "local1:=25" ends up to a call

aContext tempAt: self indexFromIR put: aValue

but the index (indexFromIR) can be different for every context (method context / inner block

context(s)).

2. Question: should the index be always the same?

thanks inadvance

 

Nicolai

 

ps: since spur (resp. compiler changes that were done for new spur images), the index of tempvars can be different.
In pre-spur, this testcase modifies an outer context var, but one that isn't checked (the argument "two"), therefore

the test succeed. In spur, this testcase modifes a different outer context var "remote1", and the test

fails.