debugging object memory

Frank Shearar frank.shearar at gmail.com
Sun Feb 10 17:57:07 UTC 2013


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 <noah.evans at gmail.com> 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 <noah.evans at gmail.com> 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
> Spoon at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon


More information about the Spoon mailing list