|
From: Alan <al...@me...> - 2003-10-17 15:55:15
|
Hi, I'm trying to use valgrind on a custom image processing program on a laptop with RH 7.2, and NVidia GeForce2Go chipset, and NV's most recent drivers (4496). I get tons of errors from the libGL routines as expected, however setting __GL_FORCE_GENERIC_CPU=1 doesn't seem to help at all! I would test on something more standardized like "glxgears", but unfortunately it isn't in my distribution (perish the thought of upgrading X and all its dependencies from 4.1.0 to current!) and I haven't seen a standalone package to build it from. At the end of this email is the output from a valgrind run (with some extraneous stuff clipped). My questions: 1) If the problem is related to the hardware-based libGL calls from the NV drivers, is there a simple way to turn off hardware acceleration so that valgrind would run without errors? 2) Is this related to special CPU instructions? Why doesn't __GL_FORCE_GENERIC_CPU=1 seem to do anything? 3) Is there a quick/easy way for me to build glxgears to make testing valgrind on GL hardware a bit more uniform (eg, eliminates behavior specific to my image processing program)? Thanks for any insight into this problem and also for the all the effort on valgrind. --Alan BTW, for the records, I don't have the "tls" directory tree. The only files are: [root@ripple root]# locate libGL. /usr/lib/libGL.so /usr/lib/libGL.so.1.0.4496 /usr/lib/libGL.so.1 valgrind output follows: [astein@ripple ~]$ valgrind display 0 0 0 1 ==2551== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==2551== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==2551== Using valgrind-20031012, a program supervision framework for x86-linux.==2551== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==2551== Warning: set address range perms: large range 130834432, a 0, v 0 ==2551== Estimated CPU clock rate is 996 MHz ==2551== For more details, rerun with: -v ==2551== ==2551== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains uninitialised or unaddressable byte(s) ==2551== at 0x404F18D8: (within /usr/lib/libGL.so.1.0.4496) ==2551== Address 0xBFFFF4C0 is on thread 1's stack ==2551== ... ==2551== ==2551== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) ==2551== by 0x40511649: NvRmAllocRoot (in /usr/lib/libGL.so.1.0.4496) ==2551== by 0x4050BC9E: (within /usr/lib/libGL.so.1.0.4496) ==2551== Address 0xBFFFF120 is on thread 1's stack ==2551== Warning: set address range perms: large range 134217728, a 0, v 0 ==2551== ==2551== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) ==2551== by 0x4050BDCA: (within /usr/lib/libGL.so.1.0.4496) ==2551== Address 0xBFFFF118 is on thread 1's stack ==2551== ... ==2551== ==2551== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) ==2551== by 0x40BD5FBE: (within /usr/lib/libGLcore.so.1.0.4496) ==2551== Address 0xBFFFF0CC is on thread 1's stack ==2551== ==2551== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) ==2551== by 0x40BD600A: (within /usr/lib/libGLcore.so.1.0.4496) ==2551== Address 0xBFFFF0CC is on thread 1's stack ... ==2551== ==2551== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) ==2551== by 0x405121B7: NvRmFree (in /usr/lib/libGL.so.1.0.4496) ==2551== by 0x40BC4300: __nvsym15143 (in usr/lib/libGLcore.so.1.0.4496) ==2551== Address 0xBFFFF1D0 is on thread 1's stack ==2551== ==2551== ERROR SUMMARY: 3055 errors from 96 contexts (suppressed: 58 from 5) ==2551== malloc/free: in use at exit: 2340679 bytes in 4405 blocks. ==2551== malloc/free: 8945 allocs, 4540 frees, 4917877 bytes allocated. ==2551== For a detailed leak analysis, rerun with: --leak-check=yes ==2551== For counts of detected errors, rerun with: -v [astein@ripple ~]$ |
|
From: <aho...@es...> - 2003-10-17 16:05:58
|
It would seem that Alan (al...@me...) said: > I would test on something more standardized like "glxgears", but > unfortunately it isn't in my distribution (perish the thought of > upgrading X and all its dependencies from 4.1.0 to current!) and I > haven't seen a standalone package to build it from. > You can get it here: http://cvs.sourceforge.net/viewcvs.py/*checkout*/mesa3d/Mesa/xdemos/glxgears.c cheers, aaron |
|
From: Paul A. C. <pa...@us...> - 2003-10-17 19:25:17
|
Alan, __GL_FORCE_GENERIC_CPU=1 is only intended to keep the library from using special instructions which may not yet be supported by valgrind (thus keeping valgrind from working *at all*). The errors you see I see as well (although I'm on 4363), and guess that they are "don't care" cases in the NV libs. The best I was able to do was to tell Valgrind to suppress the errors (run with --gen-suppressions=yes, save generated suppressions to a file, say $HOME/.valgrind/NV.suppress, then run again with --suppressions=$HOME/.valgrind/NV.suppress). Regards, Paul Clarke On Fri, 2003-10-17 at 10:54, Alan wrote: > I get tons of errors from the libGL routines as expected, however > setting __GL_FORCE_GENERIC_CPU=1 doesn't seem to help at all! > > I would test on something more standardized like "glxgears", but > unfortunately it isn't in my distribution (perish the thought of > upgrading X and all its dependencies from 4.1.0 to current!) and I > haven't seen a standalone package to build it from. > > At the end of this email is the output from a valgrind run (with some > extraneous stuff clipped). > > My questions: > 1) If the problem is related to the hardware-based libGL calls from the > NV drivers, is there a simple way to turn off hardware acceleration so > that valgrind would run without errors? > 2) Is this related to special CPU instructions? Why doesn't > __GL_FORCE_GENERIC_CPU=1 seem to do anything? > 3) Is there a quick/easy way for me to build glxgears to make testing > valgrind on GL hardware a bit more uniform (eg, eliminates behavior > specific to my image processing program)? > > Thanks for any insight into this problem and also for the all the effort > on valgrind. > > --Alan > > > BTW, for the records, I don't have the "tls" directory tree. The only > files are: > > [root@ripple root]# locate libGL. > /usr/lib/libGL.so > /usr/lib/libGL.so.1.0.4496 > /usr/lib/libGL.so.1 > > valgrind output follows: > > > > [astein@ripple ~]$ valgrind display 0 0 0 1 > ==2551== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. > ==2551== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. > ==2551== Using valgrind-20031012, a program supervision framework for > x86-linux.==2551== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. > ==2551== Warning: set address range perms: large range 130834432, a 0, v 0 > ==2551== Estimated CPU clock rate is 996 MHz > ==2551== For more details, rerun with: -v > ==2551== > ==2551== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains > uninitialised or unaddressable byte(s) > ==2551== at 0x404F18D8: (within /usr/lib/libGL.so.1.0.4496) > ==2551== Address 0xBFFFF4C0 is on thread 1's stack > ==2551== > ... > ==2551== > ==2551== Syscall param ioctl(generic) contains uninitialised or > unaddressable byte(s) > ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) > ==2551== by 0x40511649: NvRmAllocRoot (in /usr/lib/libGL.so.1.0.4496) > ==2551== by 0x4050BC9E: (within /usr/lib/libGL.so.1.0.4496) > ==2551== Address 0xBFFFF120 is on thread 1's stack > ==2551== Warning: set address range perms: large range 134217728, a 0, v 0 > ==2551== > ==2551== Syscall param ioctl(generic) contains uninitialised or > unaddressable byte(s) > ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) > ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) > ==2551== by 0x4050BDCA: (within /usr/lib/libGL.so.1.0.4496) > ==2551== Address 0xBFFFF118 is on thread 1's stack > ==2551== > ... > ==2551== > ==2551== Syscall param ioctl(generic) contains uninitialised or > unaddressable byte(s) > ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) > ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) > ==2551== by 0x40BD5FBE: (within /usr/lib/libGLcore.so.1.0.4496) > ==2551== Address 0xBFFFF0CC is on thread 1's stack > ==2551== > ==2551== Syscall param ioctl(generic) contains uninitialised or > unaddressable byte(s) > ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) > ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) > ==2551== by 0x40BD600A: (within /usr/lib/libGLcore.so.1.0.4496) > ==2551== Address 0xBFFFF0CC is on thread 1's stack > ... > ==2551== > ==2551== Syscall param ioctl(generic) contains uninitialised or > unaddressable byte(s) > ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) > ==2551== by 0x405121B7: NvRmFree (in /usr/lib/libGL.so.1.0.4496) > ==2551== by 0x40BC4300: __nvsym15143 (in usr/lib/libGLcore.so.1.0.4496) > ==2551== Address 0xBFFFF1D0 is on thread 1's stack > ==2551== > ==2551== ERROR SUMMARY: 3055 errors from 96 contexts (suppressed: 58 from 5) > ==2551== malloc/free: in use at exit: 2340679 bytes in 4405 blocks. > ==2551== malloc/free: 8945 allocs, 4540 frees, 4917877 bytes allocated. > ==2551== For a detailed leak analysis, rerun with: --leak-check=yes > ==2551== For counts of detected errors, rerun with: -v > [astein@ripple ~]$ > > > > > > > > ------------------------------------------------------- > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo > The Event For Linux Datacenter Solutions & Strategies in The Enterprise > Linux in the Boardroom; in the Front Office; & in the Server Room > http://www.enterpriselinuxforum.com > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Alan S. <al...@me...> - 2003-10-17 23:16:35
|
Paul, Aaron, Thanks much for the responses. I now have glxgears running, but it generates the same stream of errors (eg, 3000+ errors). However, using the methods you described I have generated some suppression rules (the ability to apply both --suppress=file and --generate-suppress=yes simultaneously was *very* helpful) specific to libGL which reveal bugs in the non-GL routines; exactly what I was hoping to do . Perhaps this problem (a plethora of errors from libGL in NV drivers) should be mentioned in the manual or a FAQ with a pointer to the manual for suppression of errors (the workaround). BTW, I'm not very familiar with the theory underlying the instrumentation of code, but I appreciate the way that valgrind operates directly on the binary without requiring special compilation. IMHO, this process is far more preferable than, for example, using PurifyPlus which requires configuration so that the tool can replicate all the functions and configurations of the Makefile. Regards, --Alan Paul A. Clarke wrote: >Alan, > >__GL_FORCE_GENERIC_CPU=1 is only intended to keep the library from using >special instructions which may not yet be supported by valgrind (thus >keeping valgrind from working *at all*). > >The errors you see I see as well (although I'm on 4363), and guess that >they are "don't care" cases in the NV libs. > >The best I was able to do was to tell Valgrind to suppress the errors >(run with --gen-suppressions=yes, save generated suppressions to a file, >say $HOME/.valgrind/NV.suppress, then run again with >--suppressions=$HOME/.valgrind/NV.suppress). > >Regards, >Paul Clarke > >On Fri, 2003-10-17 at 10:54, Alan wrote: > > >>I get tons of errors from the libGL routines as expected, however >>setting __GL_FORCE_GENERIC_CPU=1 doesn't seem to help at all! >> >>I would test on something more standardized like "glxgears", but >>unfortunately it isn't in my distribution (perish the thought of >>upgrading X and all its dependencies from 4.1.0 to current!) and I >>haven't seen a standalone package to build it from. >> >>At the end of this email is the output from a valgrind run (with some >>extraneous stuff clipped). >> >>My questions: >>1) If the problem is related to the hardware-based libGL calls from the >>NV drivers, is there a simple way to turn off hardware acceleration so >>that valgrind would run without errors? >>2) Is this related to special CPU instructions? Why doesn't >>__GL_FORCE_GENERIC_CPU=1 seem to do anything? >>3) Is there a quick/easy way for me to build glxgears to make testing >>valgrind on GL hardware a bit more uniform (eg, eliminates behavior >>specific to my image processing program)? >> >>Thanks for any insight into this problem and also for the all the effort >>on valgrind. >> >> --Alan >> >> >>BTW, for the records, I don't have the "tls" directory tree. The only >>files are: >> >>[root@ripple root]# locate libGL. >>/usr/lib/libGL.so >>/usr/lib/libGL.so.1.0.4496 >>/usr/lib/libGL.so.1 >> >>valgrind output follows: >> >> >> >>[astein@ripple ~]$ valgrind display 0 0 0 1 >>==2551== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. >>==2551== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. >>==2551== Using valgrind-20031012, a program supervision framework for >>x86-linux.==2551== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. >>==2551== Warning: set address range perms: large range 130834432, a 0, v 0 >>==2551== Estimated CPU clock rate is 996 MHz >>==2551== For more details, rerun with: -v >>==2551== >>==2551== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains >>uninitialised or unaddressable byte(s) >>==2551== at 0x404F18D8: (within /usr/lib/libGL.so.1.0.4496) >>==2551== Address 0xBFFFF4C0 is on thread 1's stack >>==2551== >>... >>==2551== >>==2551== Syscall param ioctl(generic) contains uninitialised or >>unaddressable byte(s) >>==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) >>==2551== by 0x40511649: NvRmAllocRoot (in /usr/lib/libGL.so.1.0.4496) >>==2551== by 0x4050BC9E: (within /usr/lib/libGL.so.1.0.4496) >>==2551== Address 0xBFFFF120 is on thread 1's stack >>==2551== Warning: set address range perms: large range 134217728, a 0, v 0 >>==2551== >>==2551== Syscall param ioctl(generic) contains uninitialised or >>unaddressable byte(s) >>==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) >>==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) >>==2551== by 0x4050BDCA: (within /usr/lib/libGL.so.1.0.4496) >>==2551== Address 0xBFFFF118 is on thread 1's stack >>==2551== >>... >>==2551== >>==2551== Syscall param ioctl(generic) contains uninitialised or >>unaddressable byte(s) >>==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) >>==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) >>==2551== by 0x40BD5FBE: (within /usr/lib/libGLcore.so.1.0.4496) >>==2551== Address 0xBFFFF0CC is on thread 1's stack >>==2551== >>==2551== Syscall param ioctl(generic) contains uninitialised or >>unaddressable byte(s) >>==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) >>==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) >>==2551== by 0x40BD600A: (within /usr/lib/libGLcore.so.1.0.4496) >>==2551== Address 0xBFFFF0CC is on thread 1's stack >>... >>==2551== >>==2551== Syscall param ioctl(generic) contains uninitialised or >>unaddressable byte(s) >>==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) >>==2551== by 0x405121B7: NvRmFree (in /usr/lib/libGL.so.1.0.4496) >>==2551== by 0x40BC4300: __nvsym15143 (in usr/lib/libGLcore.so.1.0.4496) >>==2551== Address 0xBFFFF1D0 is on thread 1's stack >>==2551== >>==2551== ERROR SUMMARY: 3055 errors from 96 contexts (suppressed: 58 from 5) >>==2551== malloc/free: in use at exit: 2340679 bytes in 4405 blocks. >>==2551== malloc/free: 8945 allocs, 4540 frees, 4917877 bytes allocated. >>==2551== For a detailed leak analysis, rerun with: --leak-check=yes >>==2551== For counts of detected errors, rerun with: -v >>[astein@ripple ~]$ >> >> >> >> >> >> >> >>------------------------------------------------------- >>This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo >>The Event For Linux Datacenter Solutions & Strategies in The Enterprise >>Linux in the Boardroom; in the Front Office; & in the Server Room >>http://www.enterpriselinuxforum.com >>_______________________________________________ >>Valgrind-users mailing list >>Val...@li... >>https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> > > > > > |
|
From: Jeremy F. <je...@go...> - 2003-10-17 21:51:59
|
On Fri, 2003-10-17 at 08:54, Alan wrote: > My questions: > 1) If the problem is related to the hardware-based libGL calls from the > NV drivers, is there a simple way to turn off hardware acceleration so > that valgrind would run without errors? > 2) Is this related to special CPU instructions? Why doesn't > __GL_FORCE_GENERIC_CPU=1 seem to do anything? No, because it isn't crashing with an illegal instruction. My guess is that the nv driver uses lots of ioctls, and Valgrind doesn't know what they do. See if --weird-hacks=lax-ioctls does anything useful for you. It may not help if the driver uses ioctls to initialize memory which is pointed to by the ioctl structure, rather than the structure itself. Also, if you're using direct rendering, there's a chunk of memory which is shared with the card itself, which Valgrind doesn't know is special (though it might be treated like any other mmaped memory). J |