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.
brad