Valgrind picks up a lot of false positives for software that does anything complicated with memory. I'd expect Mesa to fall into that category. Python supplies a Valgrind suppression file because it throws so many invalid problems in the Python interpreter see http://svn.python.org/projects/pytho...EADME.valgrind for the details.
Indeed. The headline should have been: Mesa is not providing a suppression file for Valgrind. But that doesn't sound as sensational though I guess.
Not really. Back in the day, I was working on an OpenGL based MMO, and used a Radeon card at the time. I ran the game under Valgrind using the closed source Catalyst drivers, and it hit Valgrind's 10,000,000 error limit before I even got to the account log in screen, which made it really hard to debug my program. It's not a Mesa-specific problem.
The problem is that, by default, Valgrind doesn't always understand IOCTLs or GPU memory mappings. You can add annotations to teach Valgrind about these things, which eliminates most of the problem. As someone mentioned, libdrm does this if you build it with --enable-valgrind.
On the classic i965 driver, I ran 'valgrind glxgears' and it reported no errors at all.
AFAIK it is enabled by default if valgrind is present when running the autogen.sh/configure script for libdrm. The problem is that you need to have the valgrind headers files available when you compile libdrm, so it's probably not activated in distributions that deliver binaries.
Instead of saying thank you for finding these problems and calling all available programmers to help the debug, the only poster basically says "there isn't any bugs, your program isn't working right, we're prefect and incapable of generating bugs for we're gods. 100% your fault".
And these people make the drivers? That should scare you a bit. Humility is a good feature in a person, not a bad one
You should totally learn how to read. Airlie said, explicitly, what's happening, and nothing else. Valgrind can't see some kinds of free, and generates false positives on those cases. I tell by experience, I double checked my program when Valgrind showed the errors, and it was actually freed, it just couldn't see the calls, because the program calls a custom function that locally frees. Although I think this should be done by a macro and not a function (and I will eventually fix this), it's handy to avoid writing the check for null pointers everytime, so the guy who originally wrote it made a function and he simply passed the pointer and the function checked and then freed. Coverity can see this, and got to the same conclusion that I got to, while Valgrind detected leaks because it couldn't see the frees. And he didn't say even this absolutely explains all, because he's aware that everyone makes mistakes at times.
I admit he (and everyone on mesa) should make a correct suppression file for this cases, so the actual leaks can be found without lots and lots of noise.