[BUG] in Debugger >> #newStack: optimization

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

[BUG] in Debugger >> #newStack: optimization

Christoph Thiede

Steps to reproduce:

  1. Debug it:
    [^ #foo] ensure: [#bar]
  2. Press Through two times to get into [#bar].

Expected behavior:

The stack list should look like this:


Actual behavior:
Actually, it looks like this:

Selecting the second top context reveals that the list contents are wrong:


Considerations:
The failure appears to happen in Debugger >> #newStack:, where the assumption is made that if the new stack is higher by exactly one context compared to the old one (diff = 1), then only the top context could have changed. The example shows that this assumption is wrong.
A fix for this particular issue is on the way into the inbox. However, I'm not sure whether it will be an adequate solution but not only an ugly workaround.

Is this optimization relevant at all today? I found an older screenshot (in Squeak by Example) that looks as if some previous versions of Squeak may have decompiled all blocks for the #printString representation:


Looking forward to your feedback! :-)

Best,
Christoph


Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: [BUG] in Debugger >> #newStack: optimization

Christoph Thiede

For trace: Solved via Tools-ct.952. Thanks for the review, Nicolas!


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Montag, 2. März 2020 14:48:05
An: Squeak Dev
Betreff: [squeak-dev] [BUG] in Debugger >> #newStack: optimization
 

Steps to reproduce:

  1. Debug it:
    [^ #foo] ensure: [#bar]
  2. Press Through two times to get into [#bar].

Expected behavior:

The stack list should look like this:


Actual behavior:
Actually, it looks like this:

Selecting the second top context reveals that the list contents are wrong:


Considerations:
The failure appears to happen in Debugger >> #newStack:, where the assumption is made that if the new stack is higher by exactly one context compared to the old one (diff = 1), then only the top context could have changed. The example shows that this assumption is wrong.
A fix for this particular issue is on the way into the inbox. However, I'm not sure whether it will be an adequate solution but not only an ugly workaround.

Is this optimization relevant at all today? I found an older screenshot (in Squeak by Example) that looks as if some previous versions of Squeak may have decompiled all blocks for the #printString representation:


Looking forward to your feedback! :-)

Best,
Christoph


Carpe Squeak!