[Vm-dev] Re: Another off-by-one error causing a crash
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>
>> 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 (18.104.22.16814).
> Can you send me the
> crash.dmp file? If it is still crashing for you? If so, can you evaluate
> 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.
>> 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!
More information about the Vm-dev