logo       

Squeak VM crashes (was: Re: [Newbies] Why Squeak is so sloooow?): msg#00160

lang.smalltalk.squeak.beginners

Subject: Squeak VM crashes (was: Re: [Newbies] Why Squeak is so sloooow?)

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?

Cheers,
- Andreas




<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise