Smalltalk › Pharo › Pharo Smalltalk Users

Fogbugz 13260 reappears?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

alistairgrant

Fogbugz 13260 reappears?

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

Nicolai Hess-3-2

Re: Fogbugz 13260 reappears?

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

alistairgrant

Re: Fogbugz 13260 reappears?

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

Nicolai Hess-3-2

Re: Fogbugz 13260 reappears?

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

alistairgrant

Re: Fogbugz 13260 reappears?

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

stepharo

Re: Fogbugz 13260 reappears?

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
>
>

Tudor Girba-2

Re: Fogbugz 13260 reappears?

> 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."

Nicolai Hess-3-2

Re: Fogbugz 13260 reappears?

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

alistairgrant

Re: Fogbugz 13260 reappears?

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

Nicolai Hess-3-2

Re: Fogbugz 13260 reappears?

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

alistairgrant

Re: Fogbugz 13260 reappears?

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?

stepharo

Re: Fogbugz 13260 reappears?

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
>
>
>