https://bugzilla.novell.com/show_bug.cgi?id=213321 ------- Comment #2 from geraldweber@terra.com.br 2006-10-18 08:24 MST ------- Created an attachment (id=101903) --> (https://bugzilla.novell.com/attachment.cgi?id=101903&action=view) dmidecode for Thinkpad R60e -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=213321 trenn@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|trenn@novell.com |kernel-maintainers@forge.provo.novell.com ------- Comment #4 from trenn@novell.com 2006-10-19 03:25 MST ------- No. If the machine gets too hot it would: - shutdown properly if critical temperature is reached - switch off power hard, if ACPI is not functioning correctly, machine is getting too fast too hot or no critical temp is defined Still it's strange why this only happens on the R60e... I'd recommend to run a memtest. -- 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.

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.