Squeak VM crash

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Squeak VM crash

Brad Fuller
>
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Squeak VM crash

johnmci
Well I think I mentioned before no-one has gone thru and preformed an  
audit to ensure the usage of memory address is resolves to a pointer
which resolves to an unsigned integer, then looked at all the places  
where someone is doing math or compares on that value.

To contribute a bit I'll undertaking looking at the mac carbon VM and  
put in the proper variable defs  in the osx carbon support code.

On 22-Sep-06, at 7:53 AM, Brad Fuller wrote:

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

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===



Reply | Threaded
Open this post in threaded view
|

Re: Squeak VM crash

Brad Fuller
John M McIntosh wrote:
> Well I think I mentioned before no-one has gone thru and preformed an
> audit to ensure the usage of memory address is resolves to a pointer
> which resolves to an unsigned integer, then looked at all the places
> where someone is doing math or compares on that value.
>
> To contribute a bit I'll undertaking looking at the mac carbon VM and
> put in the proper variable defs  in the osx carbon support code.
Thanks John. I logged this into Mantis: 0005056

>
> On 22-Sep-06, at 7:53 AM, Brad Fuller wrote:
>
>>>
>> 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
>>
>>
>
> --
> ===========================================================================
>
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>


--
brad fuller
sonaural: www.sonaural.com
personal: www.bradfuller.com
          www.oreillynet.com/pub/au/2184