public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/39271] New: 64 bit memory allocation possible error
@ 2009-02-23 7:58 Mike dot Warby at brunel dot ac dot uk
2009-02-23 8:03 ` [Bug c++/39271] " pinskia at gcc dot gnu dot org
0 siblings, 1 reply; 2+ messages in thread
From: Mike dot Warby at brunel dot ac dot uk @ 2009-02-23 7:58 UTC (permalink / raw)
To: gcc-bugs
Subject: Possible error with C++ compilers on 64 bit PC running
SUSE 10.3 with memory allocation
In C++ you can request space with the new command but if you
repeatedly do this then it should eventually fail. The following
program is designed to illustrate this by first repeatedly asking
for 1Mbyte until the requests fails. This is then done again
with blocks of double the size etc.
On 32 bit PCs the program behaves as expected and the output
is shown below. However on a 64 bit PC with g++ version 4.2.1
and with the Sun linux compiler CC and with the intel compiler
icc no failure is ever reported. This suggests a serious bug
in some aspect of the 64 bit system or have I made a mistake
myself?
The 64 bit PC with 4GB of RAM often runs very slowly and is
sometimes the slowest PC that I have had for many years with
many of the applications that I regularly run.
Could the above be the reason for the PC sometimes being so slow?
Any help in resolving the bug with the 64 bit system will be
appreciated. My only solution at the moment is abandon the
use of the 64 bit operating system in favour of the 32 bit
version.
..................c++ program err64.cpp follows
#include <iostream>
#include <iomanip>
using namespace std;
int main()
{
char *c;
char *a[11][8192];
int b[11];
int i, j, k, m=1024*1024;
// .. request m bytes until the request fails
for(j=0; j<11; j++)
{
for(i=0; i<8192; i++)
{
c=new (nothrow) char[m];
if(c==NULL)break;
a[j][i]=c;
}
// .. release the space
for(k=0; k<i && k<8192; k++)delete[] a[j][k];
b[j]=i;
cout << setw(3) << j
<< " m=" << setw(12) << m
<< " b[j]=" << setw(8) << b[j];
if(i>=2) cout << " pointer difference="
<< setw(12) << a[j][i-2] -a[j][i-1];
cout <<endl;
// .. double m for the next attempt
m=2*m;
}
return 0;
}
..................end of program
....output of g++ -v follows
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.2
--enable-version-specific-runtime-libs --without-system-libunwind
--with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)
....output of uname -a follows
Linux viglenvista 2.6.22.19-0.2-default #1 SMP 2008-12-18 10:17:03 +0100 x86_64
x86_64 x86_64 GNU/Linux
The compilation was done with the command
g++ err64.cpp
...output on 64 bit PC with 4GB of memory
...I did not expect all 8192 requests to succeed for every value of m.
0 m= 1048576 b[j]= 8192 pointer difference= -1052672
1 m= 2097152 b[j]= 8192 pointer difference= -2101248
2 m= 4194304 b[j]= 8192 pointer difference= -4198400
3 m= 8388608 b[j]= 8192 pointer difference= -8392704
4 m= 16777216 b[j]= 8192 pointer difference= -16781312
5 m= 33554432 b[j]= 8192 pointer difference= -33558528
6 m= 67108864 b[j]= 8192 pointer difference= -67112960
7 m= 134217728 b[j]= 8192 pointer difference= -134221824
8 m= 268435456 b[j]= 8192 pointer difference= -268439552
9 m= 536870912 b[j]= 8192 pointer difference= -536875008
10 m= 1073741824 b[j]= 8192 pointer difference= -1073745920
...output on 32 bit PC with 1GB of memory and about 1GB of swap space
...this is approximately what I expected to happen
0 m= 1048576 b[j]= 1609 pointer difference= -1052672
1 m= 2097152 b[j]= 806 pointer difference= -2101248
2 m= 4194304 b[j]= 403 pointer difference= -4198400
3 m= 8388608 b[j]= 201 pointer difference= -8392704
4 m= 16777216 b[j]= 100 pointer difference= -16781312
5 m= 33554432 b[j]= 50 pointer difference= -33558528
6 m= 67108864 b[j]= 25 pointer difference= -67112960
7 m= 134217728 b[j]= 12 pointer difference= -134221824
8 m= 268435456 b[j]= 6 pointer difference= -268439552
9 m= 536870912 b[j]= 3 pointer difference= -536875008
10 m= 1073741824 b[j]= 1
--
Summary: 64 bit memory allocation possible error
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Mike dot Warby at brunel dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39271
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug c++/39271] 64 bit memory allocation possible error
2009-02-23 7:58 [Bug c++/39271] New: 64 bit memory allocation possible error Mike dot Warby at brunel dot ac dot uk
@ 2009-02-23 8:03 ` pinskia at gcc dot gnu dot org
0 siblings, 0 replies; 2+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2009-02-23 8:03 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-23 08:02 -------
Why don't you think all would work? So you are asking for only 8Gig of memory.
On a 64bit machine it should work because of virtual memory. Anyways the
nothrow version of operator new, just call directly malloc, so it is up to the
libc to do the right thing.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39271
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-02-23 8:03 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-23 7:58 [Bug c++/39271] New: 64 bit memory allocation possible error Mike dot Warby at brunel dot ac dot uk
2009-02-23 8:03 ` [Bug c++/39271] " pinskia at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).