Hi,
Um, yes, I know you've discussed this before, but....
I'm not sure it's just a gcc 4.3.2 problem.
I downloaded and poked at the tar file of 3.10-4's source. I got this from http://squeakvm.org/unix/.
The error message comes from uxGrowMemoryBy, but, I think it comes from being called (two frames higher) in incrementalGC.
The code is (from the gnu-interp.c file, though interp.c is the same):
if (((((usqInt) ((longAt(foo->freeBlock)) & AllButTypeMask))) < (((usqInt) foo->growHeadroom))) && (foo->gcBiasToGrow > 0)) { /* begin biasToGrow */ /* begin growObjectMemory: */ foo->statGrowMemory += 1; limit = sqGrowMemoryBy(foo->memoryLimit, growSize); if (!(limit == foo->memoryLimit)) { foo->memoryLimit = limit - 24; initializeMemoryFirstFree(foo->freeBlock); } weDidGrow = 1; }
So we call sqGrowMemoryBy with growSize which is used to calculate newDelta in uxGrowMemoryBy.
A search of incrementalGC though shows that growSize, a sqInt is declared it's never set. It turns out that with my system (Debian Lenny ppc, with gcc 4.3.2) growSize is zeroed. Maybe that's the 'problem' with gcc 4.3.2?
If I set it to some number, say, 100000, then a print statement just before sqGrowMemoryBy comes out and squeak grows its memory, and, volia, no crash.
Now, this might just be bypassing the real problem, but, it's unclear to me how an uninitialized growSize would be a good idea.
This also explains why my previous workaround, using the flag -memory on the command line, caused the problem to not occur.
cheers
bruce
On Thu, Feb 19, 2009 at 09:18:49AM -0800, John M McIntosh wrote:
look in the archive and on the vm-dev list I think people agree this is a gcc 4.3 issue.
On 19-Feb-09, at 4:15 AM, Bruce O'Neel wrote:
Hi,
Is it possible this error?
sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0` failed. Aborted
I get this following the procedure below on a Debian Lenny PPC system with Squeak 3.10-4. Gcc is 4.3.2. I do not get this on a Ubuntu hardy ppc system with the same version of squeak. Gcc is slightly older at 4.2.3.
I've worked around this, for the moment, by adding -memory 200m to the squeak command line.
I spent some weekend debugging this, but, I didn't find where the problem it is comes from.
cheers
bruce
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project