Hi,
with a recent stock pharo image and a new VM compiled from svn on Linux, I always get
squeak: /tmp/squeak-svn/platforms/unix/vm/sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0' failed. Aborted
This does not happen on Squeak 3.9 nor 3.10. This did not happen yesterday when I was on Ubuntu Hardy. Now, I'm on Intrepid, GCC 4.3.2 and it crashes after 3 seconds of work on any Pharo image.
You may want to know that to compile the vm, I was obliged to change sqUnixFBDevMousePS2.c to make use of the 'write(2)' return value because my compiler didn't want to compile if write(2) return value was unused.
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.
Cheers, - Andreas
Damien Cassou wrote:
Hi,
with a recent stock pharo image and a new VM compiled from svn on Linux, I always get
squeak: /tmp/squeak-svn/platforms/unix/vm/sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0' failed. Aborted
This does not happen on Squeak 3.9 nor 3.10. This did not happen yesterday when I was on Ubuntu Hardy. Now, I'm on Intrepid, GCC 4.3.2 and it crashes after 3 seconds of work on any Pharo image.
You may want to know that to compile the vm, I was obliged to change sqUnixFBDevMousePS2.c to make use of the 'write(2)' return value because my compiler didn't want to compile if write(2) return value was unused.
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 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?
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
David T. Lewis 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.
Cheers, - Andreas
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 11:15:02AM +0100, Damien Cassou wrote:
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?
Something is going wrong in the call to valign. I can't quite spot it, but note that valign(x) is {(x) & pageMask}, where pageMask is 0xfffff000. Your newDelta result is -4096, which also happens to be 0xfffff000.
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.
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.
Dave
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 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.
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
On Wed, Feb 4, 2009 at 1:55 AM, David T. Lewis lewis@mail.msen.com wrote:
Still, it's worth asking the question, what version of VMMaker are you using?
I do not use VMMaker. I've just downloaded the sources from the subversion repository and executed configure, make and make install in a separate bld directory.
On 30.01.2009, at 08:47, Damien Cassou wrote:
You may want to know that to compile the vm, I was obliged to change sqUnixFBDevMousePS2.c to make use of the 'write(2)' return value because my compiler didn't want to compile if write(2) return value was unused.
You're sure you're using the latest from SVN? What about this commit?
r1954 | piumarta | 2008-11-24 20:32:02 +0100 (Mo, 24 Nov 2008) | 1 line Changed paths: M /trunk/platforms/unix/ChangeLog M /trunk/platforms/unix/vm-display-fbdev/sqUnixFBDevMousePS2.c PS2 driver explicitly ignores the return value from write()
- Bert -
On Fri, Jan 30, 2009 at 9:15 AM, Bert Freudenberg bert@freudenbergs.de wrote:
You're sure you're using the latest from SVN? What about this commit?
I'm sure because I did a checkout on a new directory. The line I changed looked like:
(void) write(...);
It seems gcc 4.3.2 just ignores the (void) and consider the return value unused.
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Damien Cassou -
David T. Lewis