Created attachment 97867 [details] valgrind log (bzip2) I'm trying to run the wine tests on my laptop under valgrind. When running the graphics tests, valgrind goes nuts in the i965 driver. The first time I ran it, It threw an error that it hit over 10 million (!) errors and was quitting. After a couple hours playing with suppressions and eventually exluding practically anything invoving i965/libdrm_intel.so, I was able to get results. As a testcase, I tried valgrinding glxgears instead, and was able to reproduce it there as well: ==19571== More than 10000000 total errors detected. I'm not reporting any more. ==19571== Final error counts will be inaccurate. Go fix your program! ==19571== Rerun with --error-limit=no to disable this cutoff. Note ==19571== that errors may occur in your program without prior warning from ==19571== Valgrind, because errors are no longer being displayed. to reproduce: valgrind -q --trace-children=yes --track-origins=yes --gen-suppressions=all --leak-check=full --num-callers=20 --workaround-gcc296-bugs=yes --vex-iropt-register-updates=allregs-at-mem-access glxgears let glxgears run for a few seconds, then close valgrind 3.9.0 OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.0.4 OpenGL core profile shading language version string: 3.30 OpenGL version string: 3.0 Mesa 10.0.4 OpenGL shading language version string: 1.30
Hi Austin, I'm guessing you don't have libdrm compiled with Valgrind support. If you have Valgrind installed when compiling libdrm, it should automatically detect it and add annotations that teach Valgrind about the various memory mappings and ioctls we do. I just ran glxgears under Valgrind and saw 0 errors. If you still see problems after rebuilding libdrm, feel free to reopen. --Ken
(In reply to comment #1) > Hi Austin, > > I'm guessing you don't have libdrm compiled with Valgrind support. If you > have Valgrind installed when compiling libdrm, it should automatically > detect it and add annotations that teach Valgrind about the various memory > mappings and ioctls we do. > > I just ran glxgears under Valgrind and saw 0 errors. > > If you still see problems after rebuilding libdrm, feel free to reopen. > > --Ken Thanks. After googling how to rebuild rpm's from source, I added valgrind to the deps, rebuilt, reinstalled, and glxgears is clean (aside from its own leaks). Thanks for your help.
> Thanks. After googling how to rebuild rpm's from source, I added valgrind to > the deps, rebuilt, reinstalled, and glxgears is clean (aside from its own > leaks). I've re-compiled libdrm after installing the vagrant package and I still have tons of errors on glxgears with valgrind --leak-check=full. valgrind-3.10.0.SVN libdrm.so.2.4.0 GL_RENDERER = Mesa DRI Intel(R) Haswell Mobile GL_VERSION = 3.0 Mesa 9.3.0-devel (git-8bbcc43) GL_VENDOR = Intel Open Source Technology Center Please advise.
Recompiling the valgrind package, you mean? Are you closing glxgears by hitting Ctrl+C in the terminal or clicking the [X] button in the window titlebar? Both of those simply kill the application - it does not call glXDestroyContext. So everything it ever did with OpenGL leaks. If you close it by pressing the Escape key, then it will quit gracefully, calling glXDestroyContext. With DRI2, I get no leaks at all. (DRI3 apparently has a few small leaks.)
(In reply to Kenneth Graunke from comment #4) > Recompiling the valgrind package, you mean? > > Are you closing glxgears by hitting Ctrl+C in the terminal or clicking the > [X] button in the window titlebar? Both of those simply kill the > application - it does not call glXDestroyContext. So everything it ever did > with OpenGL leaks. > > If you close it by pressing the Escape key, then it will quit gracefully, > calling glXDestroyContext. With DRI2, I get no leaks at all. (DRI3 > apparently has a few small leaks.) Thanks for clarifying. Indeed, using escape shows no leaks. I do get one valrind issue, in the driver: ==32457== Syscall param ioctl(generic) points to uninitialised byte(s) ==32457== at 0x34E72F6407: ioctl (in /usr/lib64/libc-2.20.so) ==32457== by 0x34F02036C7: drmIoctl (in /usr/lib64/libdrm.so.2.4.0) ==32457== by 0x34F02061FB: drmPrimeHandleToFD (in /usr/lib64/libdrm.so.2.4.0) ==32457== by 0x57B561D: drm_intel_bo_gem_export_to_prime (in /usr/lib64/libdrm_intel.so.1.0.0) ==32457== by 0x5340807: ??? (in /usr/lib64/dri/i965_dri.so) ==32457== by 0x34F2A4E53D: ??? (in /usr/lib64/libGL.so.1.2.0) ==32457== by 0x34F2A4F389: ??? (in /usr/lib64/libGL.so.1.2.0) ==32457== by 0x535DE96: ??? (in /usr/lib64/dri/i965_dri.so) ==32457== by 0x535E1C4: ??? (in /usr/lib64/dri/i965_dri.so) ==32457== by 0x535E316: ??? (in /usr/lib64/dri/i965_dri.so) ==32457== by 0x52FEE95: ??? (in /usr/lib64/dri/i965_dri.so) ==32457== by 0x34F2A4D979: ??? (in /usr/lib64/libGL.so.1.2.0) ==32457== Address 0xffefff958 is on thread 1's stack ==32457== in frame #2, created by drmPrimeHandleToFD (???:) ==32457==
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.