> Brad Fuller wrote:
>> Reducing the array size to something like:
>> | a b |
>> a := FloatArray new: (16 * 1024*500).
>> b := FloatArray new: (16 * 1024*500).
>> [a += b] timeToRun.
>> works fine.
>> the only thing I can think of is that I'm running out of total memory
>> (physical+swap). With my total physical memory of 512MB and swap of 1GB,
>> I would run out of memory with the original test case. If this is the
>> case, is there not a safe guard in Squeak to prevent this crash?
> I think it's got nothing to do with it (and you guys should really
> change the subject line if you're discussing crashes and want people
> to notice your discussion). Looking at the thread, there is a dead
> giveaway of the problem in the stack trace right here:
> -2128068296 HandMorph>sendMouseEvent:
> -2128068388 HandMorph>handleEvent:
> -2128068768 MouseOverHandler>processMouseOver:
> 2032428416 HandMorph>handleEvent:
> 2032428116 HandMorph>processEvents
> 2032428208  in WorldState>doOneCycleNowFor:
> 2032428024 SequenceableCollection>do:
> Your memory was allocated partially in the lower and partially in the
> upper half of the 32bit address range. Looks like by allocating "just
> enough" you're tipping it over to the other half of memory and my
> guess would be that this is what's killing it, e.g., some
> signed/unsigned/pointer arithmetic problem. And some plugin might
> cause that as well, possibly even the FloatArrayPlugin itself (I don't
> think anyone has ever reviewed it for those kinds of issues).
> Sigh. We should have a debug option in the VM that allows allocating
> the object memory at a specific address for testing this kind of
> behavior. Any takers?
I'm dumb... my apologies. <Bang Head>
That's a serious issue. I don't see a FloatArrayPlugin. Is it the
FloatMathPlugin? It has some cross platform code. So, if it is from
this, it's a potential problem for all platforms.
But, as you said it could be anywhere. Still, a serious issue.