Fogbugz 13260 reappears?

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

Fogbugz 13260 reappears?

alistairgrant
Hi All,

I'm currently regularly hitting an issue with the debugger where
inspecting a temporary variable shows the string "error obtaining field
value" rather than the actual value.

Selecting the temporary variable and attempting to inspect it in the
code pane results in:

True(Object)>>doesNotUnderstand: #indexInTempVectorFromIR:
OCVectorTempVariable>>searchFromContext:scope:
DebuggerMethodMapOpal>>tempNamed:in:
DebuggerMethodMapOpal>>namedTempAt:in:
Context>>namedTempAt:
GlorpSession>>DoItIn:
OpalCompiler>>evaluate
RubSmalltalkEditor>>evaluate:andDo:
RubSmalltalkEditor>>highlightEvaluateAndDo:
[ textMorph textArea editor highlightEvaluateAndDo: ann action.
textMorph shoutStyler style: textMorph text ] in [ textMorph textArea
        handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action.
                textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoMethodRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea editor highlightEvaluateAndDo...etc...
RubEditingArea(RubAbstractTextArea)>>handleEdit:
[ textMorph textArea
        handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action.
                textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoMethodRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea...
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldState>>doOneSubCycleFor:
WorldMorph>>doOneSubCycle
MenuMorph>>invokeModalAt:in:allowKeyboard:
MenuMorph>>invokeModal:
MenuMorph>>invokeModal
[ :menu |
menu setInvokingView: self editor.
menu invokeModal.
self changed.
^ true ] in RubEditingArea(RubAbstractTextArea)>>yellowButtonActivity: in Block: [ :menu | ...
MenuMorph(Object)>>ifNotNilDo:
RubEditingArea(RubAbstractTextArea)>>yellowButtonActivity:
RubEditingArea(RubAbstractTextArea)>>mouseDown:
RubEditingArea(Morph)>>handleMouseDown:
MouseButtonEvent>>sentTo:
RubEditingArea(Morph)>>handleEvent:
MorphicEventDispatcher>>dispatchMouseDown:with:
MorphicEventDispatcher>>handleMouseDown:

This is in:

Pharo5.0
Latest update: #50757

OS: 4.6.2-1-ARCH

It appears to be a resurrection of https://pharo.fogbugz.com/f/cases/13260/

I'm hitting the problem by executing (using the example from the Glorp
chapter in Pharo in Progress):

        session
                inUnitOfWorkDo: [ | person |
                        person := session readOneOf: Person where: [ :each | each lastName = 'Locke' ].
                        person birthDate: Date today ]


Stepping in to GlorpSession>>inUnitOfWorkDo: and attempting to inspect
'result' after it has been assigned.

Is this a known problem, should I open a new issue, or...?

Thanks!
Alistair

Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

Nicolai Hess-3-2


2016-06-24 20:57 GMT+02:00 Alistair Grant <[hidden email]>:
Hi All,

I'm currently regularly hitting an issue with the debugger where
inspecting a temporary variable shows the string "error obtaining field
value" rather than the actual value.

I am not sure if this is the same error. We had a couple of issues with reading different kinds of variables in the debugger,
and some fix work for one access and introduces new issues for other kinds of variables :(

Most things are working now, but we have still an issue in Pharo 6.0 with block local vars in optimized blocks (case 17343)
But I think this one is a different issue.
Before we open a new issue, it would be good if I can reproduce this one.
Give me some time ( or some hints) what I need to reproduce this)

 
Selecting the temporary variable and attempting to inspect it in the
code pane results in:

True(Object)>>doesNotUnderstand: #indexInTempVectorFromIR:
OCVectorTempVariable>>searchFromContext:scope:
DebuggerMethodMapOpal>>tempNamed:in:
DebuggerMethodMapOpal>>namedTempAt:in:
Context>>namedTempAt:
GlorpSession>>DoItIn:
OpalCompiler>>evaluate
RubSmalltalkEditor>>evaluate:andDo:
RubSmalltalkEditor>>highlightEvaluateAndDo:
[ textMorph textArea editor highlightEvaluateAndDo: ann action.
textMorph shoutStyler style: textMorph text ] in [ textMorph textArea
        handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action.
                textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoMethodRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea editor highlightEvaluateAndDo...etc...
RubEditingArea(RubAbstractTextArea)>>handleEdit:
[ textMorph textArea
        handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action.
                textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoMethodRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea...
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldState>>doOneSubCycleFor:
WorldMorph>>doOneSubCycle
MenuMorph>>invokeModalAt:in:allowKeyboard:
MenuMorph>>invokeModal:
MenuMorph>>invokeModal
[ :menu |
menu setInvokingView: self editor.
menu invokeModal.
self changed.
^ true ] in RubEditingArea(RubAbstractTextArea)>>yellowButtonActivity: in Block: [ :menu | ...
MenuMorph(Object)>>ifNotNilDo:
RubEditingArea(RubAbstractTextArea)>>yellowButtonActivity:
RubEditingArea(RubAbstractTextArea)>>mouseDown:
RubEditingArea(Morph)>>handleMouseDown:
MouseButtonEvent>>sentTo:
RubEditingArea(Morph)>>handleEvent:
MorphicEventDispatcher>>dispatchMouseDown:with:
MorphicEventDispatcher>>handleMouseDown:

This is in:

Pharo5.0
Latest update: #50757

OS: 4.6.2-1-ARCH

It appears to be a resurrection of https://pharo.fogbugz.com/f/cases/13260/

I'm hitting the problem by executing (using the example from the Glorp
chapter in Pharo in Progress):

        session
                inUnitOfWorkDo: [ | person |
                        person := session readOneOf: Person where: [ :each | each lastName = 'Locke' ].
                        person birthDate: Date today ]


Stepping in to GlorpSession>>inUnitOfWorkDo: and attempting to inspect
'result' after it has been assigned.

Is this a known problem, should I open a new issue, or...?

Thanks!
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

alistairgrant
Hi Nicolai,

On Fri, Jun 24, 2016 at 09:15:41PM +0200, Nicolai Hess wrote:

>
>
> 2016-06-24 20:57 GMT+02:00 Alistair Grant <[hidden email]>:
>
>     Hi All,
>
>     I'm currently regularly hitting an issue with the debugger where
>     inspecting a temporary variable shows the string "error obtaining field
>     value" rather than the actual value.
>
>
> I am not sure if this is the same error. We had a couple of issues with reading
> different kinds of variables in the debugger,
> and some fix work for one access and introduces new issues for other kinds of
> variables :(
>
> Most things are working now, but we have still an issue in Pharo 6.0 with block
> local vars in optimized blocks (case 17343)
> But I think this one is a different issue.
> Before we open a new issue, it would be good if I can reproduce this one.
> Give me some time ( or some hints) what I need to reproduce this)

Thanks for your reply.

I've created a class that reproduces the problem:


'From Pharo5.0 of 16 April 2015 [Latest update: #50757] on 24 June 2016 at 9:51:07.97744 pm'!
Object subclass: #AKGDebuggerBug
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'AKG-Bugs'!

!AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:49'!
method1
        "AKGDebuggerBug new method1"
        self method2: [ 'hello world' ].! !

!AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'!
method3: aBlock

        | result |
       
        [ result := aBlock value ] value.
        ^result.! !

!AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'!
method2: aBlock
        | result |
        [ result := aBlock numArgs = 1
                ifTrue: [ aBlock value: self ]
                ifFalse: [ aBlock value ] ] value.
        ^ result! !


Debugging "AKGDebuggerBug new method1" and stepping through to where
result is assigned in method2: will trigger the problem.

Note that modifying method1 to call method3: will not reproduce the
problem.


Thanks,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

Nicolai Hess-3-2
Can you try if this is working with this change (attach .st)
I'll open an issue and do some more tests.


2016-06-24 21:56 GMT+02:00 Alistair Grant <[hidden email]>:
Hi Nicolai,

On Fri, Jun 24, 2016 at 09:15:41PM +0200, Nicolai Hess wrote:
>
>
> 2016-06-24 20:57 GMT+02:00 Alistair Grant <[hidden email]>:
>
>     Hi All,
>
>     I'm currently regularly hitting an issue with the debugger where
>     inspecting a temporary variable shows the string "error obtaining field
>     value" rather than the actual value.
>
>
> I am not sure if this is the same error. We had a couple of issues with reading
> different kinds of variables in the debugger,
> and some fix work for one access and introduces new issues for other kinds of
> variables :(
>
> Most things are working now, but we have still an issue in Pharo 6.0 with block
> local vars in optimized blocks (case 17343)
> But I think this one is a different issue.
> Before we open a new issue, it would be good if I can reproduce this one.
> Give me some time ( or some hints) what I need to reproduce this)

Thanks for your reply.

I've created a class that reproduces the problem:


'From Pharo5.0 of 16 April 2015 [Latest update: #50757] on 24 June 2016 at 9:51:07.97744 pm'!
Object subclass: #AKGDebuggerBug
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'AKG-Bugs'!

!AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:49'!
method1
        "AKGDebuggerBug new method1"
        self method2: [ 'hello world' ].! !

!AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'!
method3: aBlock

        | result |

        [ result := aBlock value ] value.
        ^result.! !

!AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'!
method2: aBlock
        | result |
        [ result := aBlock numArgs = 1
                ifTrue: [ aBlock value: self ]
                ifFalse: [ aBlock value ] ] value.
        ^ result! !


Debugging "AKGDebuggerBug new method1" and stepping through to where
result is assigned in method2: will trigger the problem.

Note that modifying method1 to call method3: will not reproduce the
problem.


Thanks,
Alistair




outerscope_temp_vector_var.cs (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

alistairgrant
Hi Nicolai,

On Fri, Jun 24, 2016 at 11:22:07PM +0200, Nicolai Hess wrote:
> Can you try if this is working with this change (attach .st)
> I'll open an issue and do some more tests.

Yep, that works, I can inspect the variable correctly in both the demo
code I posted and the original code that triggered the problem.

Thanks!
Alistair

Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

stepharo
Thanks you guys this is really cool to see you working like that!


Le 24/6/16 à 23:45, Alistair Grant a écrit :

> Hi Nicolai,
>
> On Fri, Jun 24, 2016 at 11:22:07PM +0200, Nicolai Hess wrote:
>> Can you try if this is working with this change (attach .st)
>> I'll open an issue and do some more tests.
> Yep, that works, I can inspect the variable correctly in both the demo
> code I posted and the original code that triggered the problem.
>
> Thanks!
> Alistair
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

Tudor Girba-2
+1


> On Jun 25, 2016, at 8:23 AM, stepharo <[hidden email]> wrote:
>
> Thanks you guys this is really cool to see you working like that!
>
>
> Le 24/6/16 à 23:45, Alistair Grant a écrit :
>> Hi Nicolai,
>>
>> On Fri, Jun 24, 2016 at 11:22:07PM +0200, Nicolai Hess wrote:
>>> Can you try if this is working with this change (attach .st)
>>> I'll open an issue and do some more tests.
>> Yep, that works, I can inspect the variable correctly in both the demo
>> code I posted and the original code that triggered the problem.
>>
>> Thanks!
>> Alistair
>>
>>
>
>

--
www.tudorgirba.com
www.feenk.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."


Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

Nicolai Hess-3-2
In reply to this post by Nicolai Hess-3-2
issue
18615 Can not access named temp vector from within optimized block scope
put a fix (with a new test case for this issue) in the inbox.



2016-06-24 23:22 GMT+02:00 Nicolai Hess <[hidden email]>:
Can you try if this is working with this change (attach .st)
I'll open an issue and do some more tests.



2016-06-24 21:56 GMT+02:00 Alistair Grant <[hidden email]>:
Hi Nicolai,

On Fri, Jun 24, 2016 at 09:15:41PM +0200, Nicolai Hess wrote:
>
>
> 2016-06-24 20:57 GMT+02:00 Alistair Grant <[hidden email]>:
>
>     Hi All,
>
>     I'm currently regularly hitting an issue with the debugger where
>     inspecting a temporary variable shows the string "error obtaining field
>     value" rather than the actual value.
>
>
> I am not sure if this is the same error. We had a couple of issues with reading
> different kinds of variables in the debugger,
> and some fix work for one access and introduces new issues for other kinds of
> variables :(
>
> Most things are working now, but we have still an issue in Pharo 6.0 with block
> local vars in optimized blocks (case 17343)
> But I think this one is a different issue.
> Before we open a new issue, it would be good if I can reproduce this one.
> Give me some time ( or some hints) what I need to reproduce this)

Thanks for your reply.

I've created a class that reproduces the problem:


'From Pharo5.0 of 16 April 2015 [Latest update: #50757] on 24 June 2016 at 9:51:07.97744 pm'!
Object subclass: #AKGDebuggerBug
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'AKG-Bugs'!

!AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:49'!
method1
        "AKGDebuggerBug new method1"
        self method2: [ 'hello world' ].! !

!AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'!
method3: aBlock

        | result |

        [ result := aBlock value ] value.
        ^result.! !

!AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'!
method2: aBlock
        | result |
        [ result := aBlock numArgs = 1
                ifTrue: [ aBlock value: self ]
                ifFalse: [ aBlock value ] ] value.
        ^ result! !


Debugging "AKGDebuggerBug new method1" and stepping through to where
result is assigned in method2: will trigger the problem.

Note that modifying method1 to call method3: will not reproduce the
problem.


Thanks,
Alistair




Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

alistairgrant
Hi Nicolai,

On Sat, Jun 25, 2016 at 06:54:41PM +0200, Nicolai Hess wrote:

> issue
> 18615 Can not access named temp vector from within optimized block scope
> put a fix (with a new test case for this issue) in the inbox.
>
>
>
> 2016-06-24 23:22 GMT+02:00 Nicolai Hess <[hidden email]>:
>
>     Can you try if this is working with this change (attach .st)
>     I'll open an issue and do some more tests.

Thanks again for providing this fix.  I want to stick with Pharo 5.0 for
now, would you mind letting me know if the final fix has changed from
the .cs file you sent earlier?

Cheers,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

Nicolai Hess-3-2
Hi Alistair,

it is the same fix, I just added a sunit - test.

2016-06-26 14:55 GMT+02:00 Alistair Grant <[hidden email]>:
Hi Nicolai,

On Sat, Jun 25, 2016 at 06:54:41PM +0200, Nicolai Hess wrote:
> issue
> 18615 Can not access named temp vector from within optimized block scope
> put a fix (with a new test case for this issue) in the inbox.
>
>
>
> 2016-06-24 23:22 GMT+02:00 Nicolai Hess <[hidden email]>:
>
>     Can you try if this is working with this change (attach .st)
>     I'll open an issue and do some more tests.

Thanks again for providing this fix.  I want to stick with Pharo 5.0 for
now, would you mind letting me know if the final fix has changed from
the .cs file you sent earlier?

Cheers,
Alistair



Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

alistairgrant
On Sun, Jun 26, 2016 at 03:49:00PM +0200, Nicolai Hess wrote:
> Hi Alistair,
>
> it is the same fix, I just added a sunit - test.

Great, thanks!

Cheers,
Alistair

> 2016-06-26 14:55 GMT+02:00 Alistair Grant <[hidden email]>:
>
>     Hi Nicolai,
>    
>     On Sat, Jun 25, 2016 at 06:54:41PM +0200, Nicolai Hess wrote:
>     > issue
>     > 18615 Can not access named temp vector from within optimized block scope
>     > put a fix (with a new test case for this issue) in the inbox.
>     >
>     >
>     >
>     > 2016-06-24 23:22 GMT+02:00 Nicolai Hess <[hidden email]>:
>     >
>     >     Can you try if this is working with this change (attach .st)
>     >     I'll open an issue and do some more tests.
>
>     Thanks again for providing this fix.  I want to stick with Pharo 5.0 for
>     now, would you mind letting me know if the final fix has changed from
>     the .cs file you sent earlier?

Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz 13260 reappears?

stepharo
In reply to this post by alistairgrant
we should back port it to 50 I think.

Can we tag it as such?



Le 26/6/16 à 14:55, Alistair Grant a écrit :

> Hi Nicolai,
>
> On Sat, Jun 25, 2016 at 06:54:41PM +0200, Nicolai Hess wrote:
>> issue
>> 18615 Can not access named temp vector from within optimized block scope
>> put a fix (with a new test case for this issue) in the inbox.
>>
>>
>>
>> 2016-06-24 23:22 GMT+02:00 Nicolai Hess <[hidden email]>:
>>
>>      Can you try if this is working with this change (attach .st)
>>      I'll open an issue and do some more tests.
> Thanks again for providing this fix.  I want to stick with Pharo 5.0 for
> now, would you mind letting me know if the final fix has changed from
> the .cs file you sent earlier?
>
> Cheers,
> Alistair
>
>
>