[Vm-dev] Re: Another off-by-one error causing a crash

Frank Shearar frank.shearar at gmail.com
Wed Mar 20 13:03:32 UTC 2013

On 20 March 2013 06:48, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Frank,
> On Thu, Mar 14, 2013 at 3:47 PM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
>> Hi Eliot, Igor,
>> I think there's at least one more off-by-one error lurking in how
>> block contexts are handled. I've put an image demonstrating the
>> problem here: http://dl.dropbox.com/u/938599/compose-crash.tgz
>> The image has an inspector. If you evaluate the highlighted "self
>> parseNull" and wait a bit, after about 20s or so the image will quit
>> with "(last object overwritten)".
> Using my current VM I see no crash.  On my Mac parseNull completes in about
> 11.5 seconds.  What VM are you using?  Also what OS?

Oh dear, that's a newbie mistake on my part. It's Cog r.2701 on Linux.
I confirmed it doesn't crash on the Interpreter VM (

>  Can you send me the
> crash.dmp file?  If it is still crashing for you?  If so, can you evaluate
> e.g.
>     Smalltalk saveAs: 'parseNullCrash'.
>     self parseNull
>  and then verify that running parseNullCrash.image crashes without user
> intervention and if so, point me to the image and changes?

will run and, after about 20 seconds, hopefully crash. I _don't_ see a

Er. Well, now, that's odd. I just tried to run it on my work machine
(Cog r.2701, Ubuntu Linux on an x86_64) and it _failed_ to crash. It
worked just fine, in fact.


> AdvThanksance
>> I'm still not using FFI. You'll see in the resulting stack trace an
>> enormous number of calls to #compose:. This isn't an infinite
>> recursion. It's several thousand nested blocks, but the workspace
>> shows that this in itself isn't a problem:
>> inc := [:x | x + 1].
>> add := inc.
>> 1 to: 100000 do: [:unused | add := add compose: inc].
>> add value: 0
>> #compose: is just
>> compose: aUnaryBlock
>>         ^ [:x | self value: (aUnaryBlock value: x)].
>> If there's anything I can do to help stomp this bug, please let me know!
>> frank
> --
> best,
> Eliot

More information about the Vm-dev mailing list