Version: (using KDE Devel) Installed from: Compiled sources OS: Linux When I use valgrind with a normal application (ls, enigma,xmag,...) all works fine. However, with all KDE applications, the app run by valgrind crashes soon after start. tmg@PC1:~> valgrind --tool=cachegrind konsole ==1913== Cachegrind, an I1/D1/L2 cache profiler for x86-linux. ==1913== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote et al. ==1913== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==1913== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==1913== For more details, rerun with: -v ==1913== ==1913== ==1913== Process terminating with default action of signal 11 (SIGSEGV) ==1913== Access not within mapped region at address 0x0 ==1913== at 0x3C0CE780: _IO_vfscanf_internal (in /lib/i686/libc.so.6) ==1913== by 0x3C0DD6F0: _IO_vsscanf (in /lib/i686/libc.so.6) ==1913== by 0x3C0D8BFA: _IO_sscanf (in /lib/i686/libc.so.6) ==1913== by 0x3BCD0427: (within /usr/lib/libGL.so.1.0.6106) ==1913== ==1913== I refs: 73,100,611 ==1913== I1 misses: 1,690 ==1913== L2i misses: 1,649 ==1913== I1 miss rate: 0.0% ==1913== L2i miss rate: 0.0% ==1913== ==1913== D refs: 32,466,032 (26,374,696 rd + 6,091,336 wr) ==1913== D1 misses: 1,770,471 ( 1,765,895 rd + 4,576 wr) ==1913== L2d misses: 1,169,799 ( 1,166,480 rd + 3,319 wr) ==1913== D1 miss rate: 5.4% ( 6.6% + 0.0% ) ==1913== L2d miss rate: 3.6% ( 4.4% + 0.0% ) ==1913== ==1913== L2 refs: 1,772,161 ( 1,767,585 rd + 4,576 wr) ==1913== L2 misses: 1,171,448 ( 1,168,129 rd + 3,319 wr) ==1913== L2 miss rate: 1.1% ( 1.1% + 0.0% ) Segmentation fault I am using KDE CVS on SuSE 9.0 Professional, compiled with gcc version 3.3.1 (SuSE Linux). I hope this is not an invalid bug report, since I do not know much about valgrind.
Does this happen with all tools? or only with cachegrind? Can you try with --num-callers=24 so that we get more of a backtrace?
>Does this happen with all tools? or only with cachegrind? It happens with all tools, and only with KDE apps. >Can you try with --num-callers=24 so that we get more of a backtrace? Does not seem to change anything... tmg@PC1:~> valgrind --tool=none --num-callers=24 kdf ==1495== Nulgrind, a binary JIT-compiler for x86-linux. ==1495== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==1495== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==1495== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==1495== For more details, rerun with: -v ==1495== ==1495== ==1495== Process terminating with default action of signal 11 (SIGSEGV) ==1495== Access not within mapped region at address 0x0 ==1495== at 0x3BEF9780: _IO_vfscanf_internal (in /lib/i686/libc.so.6) ==1495== by 0x3BF086F0: _IO_vsscanf (in /lib/i686/libc.so.6) ==1495== by 0x3BF03BFA: _IO_sscanf (in /lib/i686/libc.so.6) ==1495== by 0x3BB0E177: (within /usr/lib/libGL.so.1.0.6629) ==1495== Segmentation fault The bug seems to be in /usr/lib/libGL.so.1.0.6629, which perhaps indicates a problem with my NVIDIA drivers, which are version 6629 (Kernel 2.6.9). I wonder why all KDE apps are linked to OpenGL... Indeed only OpenGL apps seem to crash, as tmg@PC1:~> valgrind --tool=none glxgears confirms. Anything else I can do?
I understand now - this is just the usual OpenGL problem caused by the code trying to test for SSE support in a really horrible way. Unfortunately it fails because valgrind doesn't provide the FPU state in the signal context when a floating point exception occurs. See bug 86641 for much more discussion of this, and bug 74298 for the underlying problems regarding FPU state in signal handlers. *** This bug has been marked as a duplicate of 74298 ***
Actually, scratch that comment. Your stack trace is all wrong for it to be that. In fact it's in a really odd place - the OpenGL drive is obviously trying to read from a file something but is presumably giving a bogus pointer to the input code or something.
I just tried glxgears on a Fedora Core 3 box with the NVidia 6629 drivers and it works fine there...
No crash here either. KDE HEAD 20041209 libGL and NVidia drivers 6629 X.org X11 R6.8 $ valgrind --version valgrind-2.2.0
Looks like it might be a TLS problem to me. It would be interesting to know what the actual faulting instruction is.
Could you build from CVS head and try again?
On Tuesday 18 January 2005 22:46, Jeremy Fitzhardinge wrote: > Could you build from CVS head and try again? Sorry, I am currently having problems with my build: > make[4]: Entering directory `/home/tmg/src/kde/valgrind/coregrind' > make[4]: *** No rule to make target `vg_proxylwp.c', needed by `stage2-vg_proxylwp.o'. Stop. This seems to be a Makefile problem, but I do not know how to resolve it. With normal KDE apps, make -f Makefile.cvs && configure normally resolves these problems, but valgrind has no Makefile.cvs. What should I do to get valgrind built ? Sorry to bother you with this, but I really don't know what to do.
That file no longer exists so the makefile shouldn't be trying to build it. I suspect you need to rerun autogen.sh to update your makefiles.
On Thursday 20 January 2005 15:09, Tom Hughes wrote: > That file no longer exists so the makefile shouldn't be trying to build > it. I suspect you need to rerun autogen.sh to update your makefiles. Did not work. > tmg@PC1:~/src/kde/valgrind> sh autogen.sh > running: aclocal > running: autoheader > configure.in:2: error: Autoconf version 2.59 or higher is required > configure.in:2: the top level > autom4te: /usr/bin/m4 failed with exit status: 1 > autoheader: /usr/bin/autom4te failed with exit status: 1 > error: while running 'autoheader' Don't tell me to update autoconf/automake. It simply does not work, I tried already. All sorts of weird stuff happens then, I guess my distro (SuSE 9.0) is too much out of date to handle newer versions. I also tried export WANT_AUTOCONF=2.57 and export WANT_AUTOMAKE=1.7, but that did not work, too. Anything else I can try? If not, this bugreport should probably be closed as I can not test the fix. Words can not describe how much I hate the autotools.
I've sent a CVS snapshot with autogen.sh already run so Thomas can try that.
On Friday 21 January 2005 00:18, Tom Hughes wrote: > I've sent a CVS snapshot with autogen.sh already run so Thomas can try > that. I've built the snapshot and valgrind now works without problems for all apps. Thanks for the snapshot and for fixing the bug!
Thanks for confirming that.