Bug: Debugger storm when trying to stepping into #withArgs:executeMethod:

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?

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
an attempt to access `arguments at: n - 2` to determine `thisReceiver`, but
as `n = 2`, this gives an error.

As I said, I do not yet understand the whole intention of this code. But why
isn't `thisReceiver` simply set to `receiver`, for n = 2? 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 ...

Complete change set:
- thisReceiver := arguments at: n - 2.
+ thisReceiver := arguments at: n - 2 ifAbsent: [receiver].

I would greatly welcome your help and explanations!

Best,
Christoph



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Hi Cristoph,

On Sun, 21 Jul 2019, Christoph Thiede wrote:

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