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
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@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
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@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@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@lists.squeakfoundation.org 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 frank.shearar@gmail.com 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 noah.evans@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@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
If it is, it ought not to be :)
frank
On 11 February 2013 19:03, Noah Evans noah.evans@gmail.com 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 frank.shearar@gmail.com 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 noah.evans@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@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
...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@lists.squeakfoundation.org
-
Craig Latta -
Frank Shearar -
Noah Evans