[squeak-dev] Bug: Debugger storm when trying to stepping into #withArgs:executeMethod:

Levente Uzonyi leves at caesar.elte.hu
Sun Jul 21 15:47:41 UTC 2019


Hi Cristoph,

On Sun, 21 Jul 2019, Christoph Thiede wrote:

> Hi all,
>
> steps to reproduce the issue:
>
> 1. Save your image (it will probably crash)
> 2. Type the following line into any CodeHolder:
> nil withArgs: #() executeMethod: Object >> #class
> 3. DebugIt and step into #withArgs:executeMethod:
>
> On my image (fairly up-to-date Trunk), the Debugger hangs and, recursively,
> new debugger windows with an "Error: subscript is out of bounds: 0" will
> open. I rarely manage to interrupt this error chain by pressing <cmd>dot ...
>
> Is this a known bug?

That is indeed a bug. It was introduced this february.

>
> I'm an absolute newbie in the matter of Debugger implementation &
> primitives, but I was curious and tried my best to localize the defect (my
> approach was debugging the debugger ...) and I found out the following: In
> the given example, in Context>>#doPrimitive:method:receiver:args: the
> primitive 188 is executed (why does the method comment speak of
> "simulation"?). Now, `arguments` is `{#(), Object >> #class}`. There is made

#doPrimitive:method:receiver:args: simulates these primitives. Here it 
simulates primitive 188, which has three different uses, each having 
different number of arguments and corresponding methods in the image. The 
methods are listed in the comment.

> an attempt to access `arguments at: n - 2` to determine `thisReceiver`, but
> as `n = 2`, this gives an error.

That is the bug. When the method has two arguments, the method is Object 
>> #withArgs:executeMethod:, and the receiver is not passed to this 
method, but the original receiver is to be used.

>
> As I said, I do not yet understand the whole intention of this code. But why
> isn't `thisReceiver` simply set to `receiver`? I exchanged this line locally
> to resolve the bug and could not find any error. But I did not found any
> automated tests for the Context class either ...

That fixes the two-argument variant (withArgs:executeMethod:), but breaks 
the simulation of the other two methods.
The proper fix is to replace the line

 		 thisReceiver := arguments at: n - 2.

with

 		 thisReceiver := arguments at: n - 2 ifAbsent: [ receiver ].

Levente

>
> I would greatly welcome your help and explanations!
>
> Best,
> Christoph
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html


More information about the Squeak-dev mailing list