I found that
- it requires the use of primitive 83 with 3 arguments (aka 
#perform:with:with:. 2 and 4 argument variants don't trigger the bug)
- its result must be passed immediately as an argument to another method 
(using a temporary to store the intermediate value won't trigger the error)
- all this has to be evaluated in a block at least twice (the first 
evaluation won't trigger the bug).

Here's a smaller example:

[ '' copyReplaceFrom: 1 to: 0 with: ('' perform: #copyFrom:to: with: 1 with: 0) ] value; value

I decided to use #copyReplaceFrom:to:with: instead of #,, because the 
former will raise a debugger due to the invalid arguments.

Here's a different one:

[ self haltIf: ({ true } perform: #at:put: with: 1 with: false) ] value; value

This clearly shows, that first argument of #perform:with:with: stays on 
the stack somehow.

Going through the code in the debugger doesn't trigger the bug, which 
makes me think that the jitted version of #perform:with:with: doesn't pop 
its first argument from the stack.

Levente

On Tue, 23 Feb 2016, Stéphane Rollandin wrote:

> I have a nice one:
>
> In (seemingly) any 5.0 image, with the latest Spur, type the following in a 
> workspace and printIt a couple of time:
>
>
> (1 to: 3) collect: [:i |
> 	m := ''.
> 	2 timesRepeat: [m := m,  ('1234' perform: #copyFrom:to: with: 2 with: 
> 4)].
> 	m]
>
>
> I get kind of randomly either #('234' '' '') or the correct #('234234' 
> '234234' '234234'), or at times #('234234' '' '').
>
>
> Attached is the same code, this time in a method. It is even funkier, since a 
> common answer is then 'copyFrom:to:234', although I sometimes get '234234' 
> ...
>
>
>
> Stef
>
>