debugging object memory

> I'm also getting an interesting floating point behavior.
>
> I'm getting a float division of 1023.0/0.0. This should be caught be
> the test !(arg != 0.0) but it isn't. Until I understand the problem
> better I'll blame the plan9 compilers. I've gotten the expected
> behavior by substituting "(int)arg == 0" which yields something close
> to the expected behavior.
>
> After digging around in the source I'd hazard a guess that the 1023.0
> value is ComponentMax in the class Color. If that's true I'd bet that
> the division comes from Color>blue. This would imply that the division
> is being done backwards and that something is potentially funky with
> my stack handling. Does anyone have any experience debugging these
> sorts of problems? printAllStacks() is unhelpful, I think this may be
> due to some bit of initialization I'm not doing.
>
> Any thoughts?
>
> Noah
>
>
> On Sun, Feb 10, 2013 at 3:51 PM, Noah Evans <[hidden email]> wrote:
>> I've got the vm receiving events (no graphics yet) and I make it to
>> the first GC.
>>
>> At oop=0x213cc94 oopSize is 34852108 which immediately causes a
>> segfault. What is the proper way to debug object memory when
>> bootstrapping?
>>
>> Noah
> _______________________________________________
> Spoon mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

> I realise you're semi-keeping a lid on this, but the folks on the
> vm-dev mailing list [1], while probably not terribly knowledgeable
> about Plan 9 in particular, do collectively have a whole lot of
> experience debugging the VMs on multiple platforms (including esoteric
> ones like RISC OS).
>
> frank
>
> [1] http://lists.squeakfoundation.org/mailman/listinfo/vm-dev
>
> On 10 February 2013 17:36, Noah Evans <[hidden email]> wrote:
>> I'm also getting an interesting floating point behavior.
>>
>> I'm getting a float division of 1023.0/0.0. This should be caught be
>> the test !(arg != 0.0) but it isn't. Until I understand the problem
>> better I'll blame the plan9 compilers. I've gotten the expected
>> behavior by substituting "(int)arg == 0" which yields something close
>> to the expected behavior.
>>
>> After digging around in the source I'd hazard a guess that the 1023.0
>> value is ComponentMax in the class Color. If that's true I'd bet that
>> the division comes from Color>blue. This would imply that the division
>> is being done backwards and that something is potentially funky with
>> my stack handling. Does anyone have any experience debugging these
>> sorts of problems? printAllStacks() is unhelpful, I think this may be
>> due to some bit of initialization I'm not doing.
>>
>> Any thoughts?
>>
>> Noah
>>
>>
>> On Sun, Feb 10, 2013 at 3:51 PM, Noah Evans <[hidden email]> wrote:
>>> I've got the vm receiving events (no graphics yet) and I make it to
>>> the first GC.
>>>
>>> At oop=0x213cc94 oopSize is 34852108 which immediately causes a
>>> segfault. What is the proper way to debug object memory when
>>> bootstrapping?
>>>
>>> Noah
>> _______________________________________________
>> Spoon mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

> Yeah I probably should. I'm a bit wary of doing this though as I
> understand it, the spoon vm is a bit different isn't it?
>
> Noah
>
>
> On Sun, Feb 10, 2013 at 6:57 PM, Frank Shearar <[hidden email]> wrote:
>> I realise you're semi-keeping a lid on this, but the folks on the
>> vm-dev mailing list [1], while probably not terribly knowledgeable
>> about Plan 9 in particular, do collectively have a whole lot of
>> experience debugging the VMs on multiple platforms (including esoteric
>> ones like RISC OS).
>>
>> frank
>>
>> [1] http://lists.squeakfoundation.org/mailman/listinfo/vm-dev
>>
>> On 10 February 2013 17:36, Noah Evans <[hidden email]> wrote:
>>> I'm also getting an interesting floating point behavior.
>>>
>>> I'm getting a float division of 1023.0/0.0. This should be caught be
>>> the test !(arg != 0.0) but it isn't. Until I understand the problem
>>> better I'll blame the plan9 compilers. I've gotten the expected
>>> behavior by substituting "(int)arg == 0" which yields something close
>>> to the expected behavior.
>>>
>>> After digging around in the source I'd hazard a guess that the 1023.0
>>> value is ComponentMax in the class Color. If that's true I'd bet that
>>> the division comes from Color>blue. This would imply that the division
>>> is being done backwards and that something is potentially funky with
>>> my stack handling. Does anyone have any experience debugging these
>>> sorts of problems? printAllStacks() is unhelpful, I think this may be
>>> due to some bit of initialization I'm not doing.
>>>
>>> Any thoughts?
>>>
>>> Noah
>>>
>>>
>>> On Sun, Feb 10, 2013 at 3:51 PM, Noah Evans <[hidden email]> wrote:
>>>> I've got the vm receiving events (no graphics yet) and I make it to
>>>> the first GC.
>>>>
>>>> At oop=0x213cc94 oopSize is 34852108 which immediately causes a
>>>> segfault. What is the proper way to debug object memory when
>>>> bootstrapping?
>>>>
>>>> Noah
>>> _______________________________________________
>>> Spoon mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon