https://bugzilla.novell.com/show_bug.cgi?id=213321
------- Comment #6 from geraldweber@terra.com.br 2006-10-19 07:27 MST -------
I've done a few other tests which perhaps may shed some light on the problem:
Consider this C code:
#include
#include
int main(void)
{
double* p;
int i;
while(1)
{
p=(double*)malloc(1000000*sizeof(double));
printf("."); //Just to tell you that it is still alive
fflush(stdout);
for(i=0; i < 1000000; i++) p[i]=0.0;
free(p);
}
}
It does essentially the same as the other C++ code, it allocates a pointer,
assigns values, and then deallocates again.
If compiled with gcc (i.e. as plain C code) this program runs happily and I
observe no hard lockups.
Now comes the interesting part: if compiled with g++ (as C++ code) it runs for
a few minutes and the machine locks up!
This is what ldd reports when compiled with gcc:
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7e4c000)
/lib/ld-linux.so.2 (0xb7f91000)
and when compiled with g++
linux-gate.so.1 => (0xffffe000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7e19000)
libm.so.6 => /lib/libm.so.6 (0xb7df4000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7de9000)
libc.so.6 => /lib/libc.so.6 (0xb7cc9000)
/lib/ld-linux.so.2 (0xb7f1e000)
I've read somewhere that libstdc++ has its own malloc function, could that be
the origin of this problem?
To test, I've wrote this code:
#include <iostream>
template<class _Tp>
class array
{
public:
typedef _Tp value_type;
typedef _Tp* pointer_type;
private:
pointer_type Array;
size_t Size;
public:
array(size_t s): Array((value_type*)malloc(s*sizeof(value_type))), Size(s)
{
for(size_t i=0; i < Size; ++i) Array[i]=value_type();
}
~array(void) {free(Array);}
};
int main(void)
{
size_t N=1000000;
while(true)
{
array<double> mat(N);
std::cout << "." << std::flush; //Just to tell you that it is still alive
}
}
which is similar to the one reported originally except that it uses an array
class that uses malloc/free instead of new/delete to allocate memory.
When compiled normally with g++ the libraries are linked in this order:
linux-gate.so.1 => (0xffffe000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7dfa000)
libm.so.6 => /lib/libm.so.6 (0xb7dd5000)
libc.so.6 => /lib/libc.so.6 (0xb7cb5000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7caa000)
/lib/ld-linux.so.2 (0xb7eff000)
as for the other program, it runs for a few minutes and causes a hard lock up.
However, when compiled like this:
gcc test.cpp -lc -lm -lgcc_s -lstdc++
the libraries show up in this order
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7e07000)
libm.so.6 => /lib/libm.so.6 (0xb7de2000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7dd7000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7cf7000)
/lib/ld-linux.so.2 (0xb7f4c000)
My guess is that it would pick up malloc from libc rather than from libstdc++
(beware: I am not sure of that!).
The thing is: this does *not* cause a hard lockup, I've run it for 1 hour
without problems (in all other cases it locks up within the first 5 minutes).
Also, I've tested the first C++ code (the one listed in this bug report) with
Intel's C++ compiler (9.1.042), it also causes a hard lockup exactly like gcc.
This compiler also links with stdc++,
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0xb7ec0000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7de0000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7dd5000)
libcxaguard.so.5 => /opt/intel/cc/9.1.042/lib/libcxaguard.so.5
(0xb7dd3000)
libc.so.6 => /lib/libc.so.6 (0xb7cb2000)
libdl.so.2 => /lib/libdl.so.2 (0xb7cae000)
/lib/ld-linux.so.2 (0xb7f0a000)
So, I am beginning to suspect that there may be some issue with the libstdc++
library, or some peculiar interaction of this library with the kernel. Perhaps,
some sort of race condition? This laptop uses a fast DDR2 667MHz memory, while
the other thinkpads tested use memories which are a lot slower. Could we be
hitting some limit here? I am just speculating, of course.
again, many thanks for your attention
Gerald
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.