Smalltalk › Pharo › Pharo Smalltalk Developers

Yet again, wrong tempvars in debuggers context variables list

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Nicolai Hess-3-2

Yet again, wrong tempvars in debuggers context variables list

This is not an issue with GTDebugger, but the way opal generates the tempvar

index or the way, debuggerMap tries to access the context vars

17660 wrong tempvar values in debugger

This is a really special case, I wasn't able yet to create an easier example for reproducing this bug:
- put a self haltOnce in
RAbstractClass>>#directlyDefinesLocalMethod:
- enable halt once
- select any other method in Nautilus and choose
"Rename method (all)" from method panes context menu
- enter a new name and push "OK"
-> the debugger pops up in method
directlyDefinesLocalMethod:
- select the first "allClassesDo:" context from top of the stack
-> the debugger shows that we are in the evalBlock context
The "seen" variable is a Set, but if you look at the "Variables"-pane, it is shown
as a block (this is actually the parameter aBlock)

Nicolai Hess-3-2

Re: Yet again, wrong tempvars in debuggers context variables list

2016-02-20 19:11 GMT+01:00 Nicolai Hess <[hidden email]>:

This is not an issue with GTDebugger, but the way opal generates the tempvar
index or the way, debuggerMap tries to access the context vars

17660 wrong tempvar values in debugger

This is a really special case, I wasn't able yet to create an easier example for reproducing this bug:
- put a self haltOnce in
RAbstractClass>>#directlyDefinesLocalMethod:
- enable halt once
- select any other method in Nautilus and choose
"Rename method (all)" from method panes context menu
- enter a new name and push "OK"
-> the debugger pops up in method
directlyDefinesLocalMethod:
- select the first "allClassesDo:" context from top of the stack
-> the debugger shows that we are in the evalBlock context
The "seen" variable is a Set, but if you look at the "Variables"-pane, it is shown
as a block (this is actually the parameter aBlock)

again, this is caused by a change for spur migration

This worked up to pharo 50496
starting with pharo 50497, the order of variables has changed.

see http://forum.world.st/pharo-project-pharo-core-dfd4f3-50497-td4867046.html

Nicolai Hess-3-2

Re: Yet again, wrong tempvars in debuggers context variables list

2016-02-20 20:31 GMT+01:00 Nicolai Hess <[hidden email]>:

2016-02-20 19:11 GMT+01:00 Nicolai Hess <[hidden email]>:
This is not an issue with GTDebugger, but the way opal generates the tempvar
index or the way, debuggerMap tries to access the context vars

17660 wrong tempvar values in debugger

This is a really special case, I wasn't able yet to create an easier example for reproducing this bug:
- put a self haltOnce in
RAbstractClass>>#directlyDefinesLocalMethod:
- enable halt once
- select any other method in Nautilus and choose
"Rename method (all)" from method panes context menu
- enter a new name and push "OK"
-> the debugger pops up in method
directlyDefinesLocalMethod:
- select the first "allClassesDo:" context from top of the stack
-> the debugger shows that we are in the evalBlock context
The "seen" variable is a Set, but if you look at the "Variables"-pane, it is shown
as a block (this is actually the parameter aBlock)

again, this is caused by a change for spur migration

This worked up to pharo 50496
starting with pharo 50497, the order of variables has changed.

see http://forum.world.st/pharo-project-pharo-core-dfd4f3-50497-td4867046.html

Any idea what has changed?

I could not spot a change that could be responsible for this.

The order of tempvars in a block context somehow changed, and the way the debugger accesses the temps

by name (get an index and access the context temp vars by index) somehow changed.

Recompiling the affected methods helps, but I would like to know if this change (where is it?) was on purpose.

Guillermo Polito

Re: Yet again, wrong tempvars in debuggers context variables list

Hmm, I know that the Spur bootstrap does a lot of changes "in the
background". For example, it replaces literals in methods
(Float->BoxedFloat64), plus it inlines all immediate characters.

I do not know if it is related, but this could be a side effect, and it
would explain why there is no evident change causing this.

On 02/22/2016 09:08 AM, Nicolai Hess wrote:

>
>
> 2016-02-20 20:31 GMT+01:00 Nicolai Hess <[hidden email]
> <mailto:[hidden email]>>:
>
>
>
> 2016-02-20 19:11 GMT+01:00 Nicolai Hess <[hidden email]
> <mailto:[hidden email]>>:
>
> This is not an issue with GTDebugger, but the way opal
> generates the tempvar
> index or the way, debuggerMap tries to access the context vars
>
> 17660
> <https://pharo.fogbugz.com/f/cases/17660/wrong-tempvar-values-in-debugger>
> wrong tempvar values in debugger
>
>
> This is a really special case, I wasn't able yet to create an
> easier example for reproducing this bug:
> - put a self haltOnce in
> RAbstractClass>>#directlyDefinesLocalMethod:
> - enable halt once
> - select any other method in Nautilus and choose
> "Rename method (all)" from method panes context menu
> - enter a new name and push "OK"
> -> the debugger pops up in method
> directlyDefinesLocalMethod:
> - select the first "allClassesDo:" context from top of the stack
> -> the debugger shows that we are in the evalBlock context
> The "seen" variable is a Set, but if you look at the
> "Variables"-pane, it is shown
> as a block (this is actually the parameter aBlock)
>
>
> again, this is caused by a change for spur migration
>
> This worked up to pharo 50496
> starting with pharo 50497, the order of variables has changed.
>
> see
> http://forum.world.st/pharo-project-pharo-core-dfd4f3-50497-td4867046.html
> <https://pharo.fogbugz.com/f/cases/17241/ffi-nb-is-not-cleaning-compiled-methods-then-they-fail-when-platform-changes>
>
>
> Any idea what has changed?
> I could not spot a change that could be responsible for this.
> The order of tempvars in a block context somehow changed, and the way
> the debugger accesses the temps
> by name (get an index and access the context temp vars by index)
> somehow changed.
> Recompiling the affected methods helps, but I would like to know if
> this change (where is it?) was on purpose.
>

Marcus Denker-4

Re: Yet again, wrong tempvars in debuggers context variables list

On 22 Feb 2016, at 10:27, Guille Polito <[hidden email]> wrote:

Hmm, I know that the Spur bootstrap does a lot of changes "in the background". For example, it replaces literals in methods (Float->BoxedFloat64), plus it inlines all immediate characters.

I do not know if it is related, but this could be a side effect, and it would explain why there is no evident change causing this.

We should have recompiled the whole image after… lets do this soon and see.

On 02/22/2016 09:08 AM, Nicolai Hess wrote:

2016-02-20 20:31 GMT+01:00 Nicolai Hess <[hidden email] <[hidden email]>>:

   2016-02-20 19:11 GMT+01:00 Nicolai Hess <[hidden email]
   <[hidden email]>>:

       This is not an issue with GTDebugger, but the way opal
       generates the tempvar
       index or the way, debuggerMap tries to access the context vars

       17660
       <https://pharo.fogbugz.com/f/cases/17660/wrong-tempvar-values-in-debugger>
       wrong tempvar values in debugger

       This is a really special case, I wasn't able yet to create an
       easier example for reproducing this bug:
       - put a self haltOnce in
       RAbstractClass>>#directlyDefinesLocalMethod:
       - enable halt once
       - select any other method in Nautilus and choose
         "Rename method (all)" from method panes context menu
       - enter a new name and push "OK"
       -> the debugger pops up in method
         directlyDefinesLocalMethod:
       - select the first "allClassesDo:" context from top of the stack
       -> the debugger shows that we are in the evalBlock context
       The "seen" variable is a Set, but if you look at the
       "Variables"-pane, it is shown
       as a block (this is actually the parameter aBlock)

   again, this is caused by a change for spur migration

   This worked up to pharo 50496
   starting with pharo 50497, the order of variables has changed.

   see
   http://forum.world.st/pharo-project-pharo-core-dfd4f3-50497-td4867046.html
   <https://pharo.fogbugz.com/f/cases/17241/ffi-nb-is-not-cleaning-compiled-methods-then-they-fail-when-platform-changes>

Any idea what has changed?
I could not spot a change that could be responsible for this.
The order of tempvars in a block context somehow changed, and the way the debugger accesses the temps
by name (get an index and access the context temp vars by index) somehow changed.
Recompiling the affected methods helps, but I would like to know if this change (where is it?) was on purpose.