debugging object memory
noah.evans at gmail.com
Mon Feb 11 19:03:26 UTC 2013
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?
On Sun, Feb 10, 2013 at 6:57 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> I realise you're semi-keeping a lid on this, but the folks on the
> vm-dev mailing list , 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).
>  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?
>> 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
>> Spoon mailing list
>> Spoon at lists.squeakfoundation.org
More information about the Spoon