Quantcast

debugging object memory

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

debugging object memory

Noah Evans
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: debugging object memory

Noah Evans
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: debugging object memory

Frank Shearar-3
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
_______________________________________________
Spoon mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: debugging object memory

Noah Evans
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
_______________________________________________
Spoon mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: debugging object memory

Frank Shearar-3
If it is, it ought not to be :)

frank

On 11 February 2013 19:03, Noah Evans <[hidden email]> wrote:

> 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
_______________________________________________
Spoon mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: debugging object memory

ccrraaiigg
In reply to this post by Noah Evans

> ...the spoon vm is a bit different isn't it?

     No, not in any way that would affect debugging. It has a dispatch
loop and primitives that support proxies, and a second garbage
collection mode for collecting methods that haven't been run recently.


-C

--
Craig Latta
www.netjam.org/resume
+31   6 2757 7177 (SMS ok)
+ 1 415 287 3547 (no SMS)

_______________________________________________
Spoon mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
Loading...