Another off-by-one error causing a crash

 
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)".

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

 
On 20 March 2013 06:48, Eliot Miranda <[hidden email]> wrote:
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 (4.10.2.2614).

>  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?

https://www.dropbox.com/sh/3vb4z572qid6lzj/jhw9mQRECR/parseNullCrash.zip
will run and, after about 20 seconds, hopefully crash. I _don't_ see a
crash.dmp.

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.

frank