Hi,
I am very sorry to insist but I would really appreciate if someone
could shed some light on my current problem. I really don't see why my
code is only segfaulting when using gcc4.0.1 (and above).
Description:
I am running a program that is outputing a file. The very same program
when run with LD_PRELOAD set to libGL.so, is segfaulting.
The backtrace can be found here:
http://www.creatis.insa-lyon.fr/~malaterre/gcc/gdb.log
And I ran also strace with/ and without LD_PRELOAD set:
$ export LD_PRELOAD=/usr/X11R6/lib/libGL.so
$ strace /home/mathieu/Dashboards/MyTests/VTK-gcc4/bin/vtkParseOGLExt
/home/mathieu/Dashboards/MyTests/VTK-gcc4/Rendering
/home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glext.h
/home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glxext.h
/home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/wglext.h
>& /tmp/log1
$ unset LD_PRELOAD
$ strace /home/mathieu/Dashboards/MyTests/VTK-gcc4/bin/vtkParseOGLExt
/home/mathieu/Dashboards/MyTests/VTK-gcc4/Rendering
/home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glext.h
/home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glxext.h
/home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/wglext.h
>& /tmp/log2
Those logs files can be found here:
http://www.creatis.insa-lyon.fr/~malaterre/gcc/log1
and
http://www.creatis.insa-lyon.fr/~malaterre/gcc/log2
-----------------------------------------------------------------------------------
Anyone interested in reproducing the bug need a debian testing with gcc4:
(assuming gcc points to gcc 4.0.1)
$ sudo apt-get install cmake
$ cvs -d:pserver:[EMAIL PROTECTED]:2401/cvsroot/VTK login
$ cvs -d:pserver:[EMAIL PROTECTED]:2401/cvsroot/VTK co VTK
$ mkdir VTK-gcc
$ cd VTK-gcc
$ cmake ../VTK
$ make
...
Thanks for any advice on tracking down this bug,
Mathieu
Mathieu Malaterre wrote:
Hello,
I have currently a reproducable seg fault from an exe produced by
gcc 4.0.1 (*). It does not appear using gcc 2.95, 3.2, 3.3, 3.4.
If I run it throught gdb I get:
0x402814b1 in __gnu_cxx::__pool<true>::_M_reclaim_block () from
/usr/lib/libstdc++.so.6
(gdb) bt
#0 0x402814b1 in __gnu_cxx::__pool<true>::_M_reclaim_block () from
/usr/lib/libstdc++.so.6
#1 0x08062907 in
__gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<std::string,
std::string> >, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>
>::deallocate (this=0x806d888, __p=0x8221f10, __n=1) at mt_allocator.h:746
...
and the structure being:
static std::set< std::pair< std::string, std::string > > foo;
If I try to run through valgrind 3.0 everything is fine, and it produce
correct output.
Any advice on a way to narrow down a simple testcase, right now it would
require building VTK(**)
Thanks for any help,
Mathieu
(*) debian testing. but I can also reproduce with gcc 4.1.0 20050726
(gcc-snapshot)
(**) http://vtk.org
