On Fri, Jan 30, 2009 at 9:00 AM, Andreas Raab andreas.raab@gmx.de wrote:

Since you're compiling the VM yourself, you might want to add a guard that catches the condition and prints out the environmental values (oldLimit, delta, newSize, newDelta). I would suspect that this is a signed/unsigned issue with memory being allocated somewhere close to the 2GB barrier and then flipping from positive to negative. Since newSize and newDelta are declared int, this could easily happen.

I've just downgraded gcc to 3.4 (instead of 4.3.2) and it seems to work fine. Do you want me to do more testing with the 4.3.2 version?

Damien Cassou wrote:

On Fri, Jan 30, 2009 at 9:00 AM, Andreas Raab andreas.raab@gmx.de wrote:

...

Since you're compiling the VM yourself, you might want to add a guard that catches the condition and prints out the environmental values (oldLimit, delta, newSize, newDelta). I would suspect that this is a signed/unsigned issue with memory being allocated somewhere close to the 2GB barrier and then flipping from positive to negative. Since newSize and newDelta are declared int, this could easily happen.

I've just downgraded gcc to 3.4 (instead of 4.3.2) and it seems to work fine. Do you want me to do more testing with the 4.3.2 version?

I really don't care - I was just trying to give you a few hints for what to look at. The other thing you could try is to compile with -O0 just to find out whether this is an optimizer problem.

Cheers, - Andreas

On Fri, Jan 30, 2009 at 09:14:33AM +0100, Damien Cassou wrote:

On Fri, Jan 30, 2009 at 9:00 AM, Andreas Raab andreas.raab@gmx.de wrote:

...

Since you're compiling the VM yourself, you might want to add a guard that catches the condition and prints out the environmental values (oldLimit, delta, newSize, newDelta). I would suspect that this is a signed/unsigned issue with memory being allocated somewhere close to the 2GB barrier and then flipping from positive to negative. Since newSize and newDelta are declared int, this could easily happen.

I've just downgraded gcc to 3.4 (instead of 4.3.2) and it seems to work fine. Do you want me to do more testing with the 4.3.2 version?

Damien,

Yes, it would be helpful if you could find out more about what is causing the bug when using gcc 4.3.2. It's probably the int declarations as Andreas suggests, and it would be good if you can confirm this.

Thanks, Dave

On Fri, Jan 30, 2009 at 02:07:33PM +0100, Damien Cassou wrote:

On Fri, Jan 30, 2009 at 9:00 AM, Andreas Raab andreas.raab@gmx.de wrote:

...

Since you're compiling the VM yourself, you might want to add a guard that catches the condition and prints out the environmental values (oldLimit, delta, newSize, newDelta). I would suspect that this is a signed/unsigned issue with memory being allocated somewhere close to the 2GB barrier and then flipping from positive to negative. Since newSize and newDelta are declared int, this could easily happen.

Here is the result of:

fprintf(stderr, "oldLimit=%p\ndelta=%d\nnewSize=%d\nnewDelta=%d\n");

oldLimit=0x80562b8 delta=-1077506096 newSize=0 newDelta=423027548 squeak: /tmp/squeak-svn/platforms/unix/vm/sqUnixMemory.c:175: uxGrowMemoryBy: Assertion `newDelta >= 0' failed.

Does it help?

Yes. I don't think newSize is supposed to be 0 here.

int newSize= min(valign(oldLimit - heap + delta), heapLimit); int newDelta= newSize - heapSize;

I'm not sure what is wrong, but apparently it's in the expression "min(valign(oldLimit - heap + delta), heapLimit)".

Dave

On Fri, Jan 30, 2009 at 6:29 PM, Andreas Raab andreas.raab@gmx.de wrote:

...

...

fprintf(stderr, "oldLimit=%p\ndelta=%d\nnewSize=%d\nnewDelta=%d\n");

oldLimit=0x80562b8 delta=-1077506096 newSize=0 newDelta=423027548 squeak: /tmp/squeak-svn/platforms/unix/vm/sqUnixMemory.c:175: uxGrowMemoryBy: Assertion `newDelta >= 0' failed.

Does it help?

Yes. I don't think newSize is supposed to be 0 here.

 int newSize=  min(valign(oldLimit - heap + delta), heapLimit);
 int newDelta= newSize - heapSize;

I'm not sure what is wrong, but apparently it's in the expression "min(valign(oldLimit - heap + delta), heapLimit)".

Could be a CSE bug. Considering that min(a,b) is usually defined as "a < b ? a : b" or so, a compiler might do something with the valign(...) expression. I would try to move the expression out of there and see if that helps.

Nobody noticed, but I did a very stupid mistake. Look at the call to fprintf that I copy/pasted in my previous mail. I forgot all the parameters :-). I don't how it is possible that gcc still compiled the code...

I moved valign out:

int align = valign(oldLimit - heap + delta); int newSize= min(align, heapLimit);

And printed the values:

if(newDelta < 0) fprintf(stderr, "oldLimit=%p\ndelta=%d\nnewSize=%d\nnewDelta=%d\nalign=%d\n",oldLimit,delta,newSize,newDelta,align);

And got:

oldLimit=0x791c8fe8 delta=0 newSize=23293952 newDelta=-4096 align=23293952 squeak: /tmp/squeak-svn/platforms/unix/vm/sqUnixMemory.c:175: uxGrowMemoryBy: Assertion `newDelta >= 0' failed. Aborted

Does that make sense to anyone?

On Sat, Jan 31, 2009 at 5:55 PM, David T. Lewis lewis@mail.msen.com wrote:

Maybe as a next step you can break out the calculation further: int argToAlign = oldLimit - heap + delta; int align = valign(argToAlign); int newSize= min(align, heapLimit);

Also printing the values of heap and heapLimit might give a clue.

int argToAlign = oldLimit - heap + delta; int align = valign(argToAlign); int newSize= min(align, heapLimit); int newDelta= newSize - heapSize; [...] if(newDelta < 0) fprintf(stderr, "oldLimit=%p\ndelta=%d\nnewSize=%d\nnewDelta=%d\nalign=%d\nargToAlign=%d\nheap=%d\nheapLimit=%d\n",oldLimit,delta,newSize,newDelta,align,argToAlign,heap,heapLimit);

oldLimit=0x79288fe8 delta=0 newSize=23293952 newDelta=-4096 align=23293952 argToAlign=23298024 heap=2009403392 heapLimit=1073741824

On Mon, Feb 02, 2009 at 12:28:49PM +0100, Damien Cassou wrote:

On Sat, Jan 31, 2009 at 5:55 PM, David T. Lewis lewis@mail.msen.com wrote:

...

Just a hunch, but I would guess that if you changed valign() from a macro to a function that it would somehow decide to start working.

I used a function and get the following results.

int myvalign(int x) { return x & pageMask; }

int argToAlign = oldLimit - heap + delta; int align = myvalign(argToAlign); int newSize= min(align, heapLimit); int newDelta= newSize - heapSize;

oldLimit=0x7929cfe8 delta=0 newSize=23293952 newDelta=-4096 align=23293952 argToAlign=23298024 heap=2009485312 heapLimit=1073741824 squeak: /tmp/squeak-svn/platforms/unix/vm/sqUnixMemory.c:181: uxGrowMemoryBy: Assertion `newDelta >= 0' failed.

Hi Damien,

I'm not sure that I can be of much help here, but for what it's worth:

I copied the numbers from your test into a small stand alone test program (attached for reference). The values that you printed all look reasonable, and I think that the problem is probably *not* in the uxGrowMemoryBy() function. The calculations up through newDelta all look correct, which suggests that either heapSize (static var in sqUnixMemory.c) or oldLimit (parameter to the function) are not set to the expected values. Of the two, I would guess that the value of oldLimit is the more likely culprit, because heapSize looks straightforward, while oldLimit is passed to the the unix support code from ObjectMemory>>growObjectMemory: (translated Slang), and goes through a pointerForOop() conversion along the way.

I'm completely guessing about the problem at this point, and obviously it was related to the version of gcc you are using. Still, it's worth asking the question, what version of VMMaker are you using?

Dave