Valgrind Finds Thousands Of Potential Issues With Mesa

[mrugiero]

Drivers are trash.

Trash is trash. Trash.

But seriously. Trash.

I hope they don't ban me. Trash trash trash.

[WorBlux]

opensource drivers are trash, more at 11.

Drivers are trash.

[kallisti5]

eeh, after spending much time going over Mesa code, I think most of this comes from the over-abundant upcasting and slicing in the Mesa code base. GL is a really tricky beast to wrangle.

[Marc Driftmeyer]

Clang Static Analyzer and Valgrind are two solid tools to flush out the bugs.

[Sidicas]

I used to think that all Valgrind errors were bugs too..
Until I started running valgrind on the popular GNU tools like ps, ls, top, etc and found Valgrind errors that appeared to be memory leaks.

Turned out, that Valgrind was complaining about some memory that wasn't explicitly being freed in code, but it doesn't matter because the memory is automatically freed when the process terminates. Adding code to explicitly free that memory would do nothing but delay the process's termination of a process that's ready to terminate, so the bug reports were closed and I learned to take Valgrind problems a lot less seriously.

Valgrind is useful in tracking down problems when you know there is a problem, but can also generate a massive amount of false positives and the few positives that it does have will often be multipled by 10,000x for the same line of code.

Edit: And also as mentioned, the kernel has got IO controlls that work with memory in ways that Valgrind doesn't know about / understand properly and so will result in a large number of false positives.. You need to filter out all the possible false positives from the ioctrls first, otherwise you're not really helping much. There's no way a dev is going to go through all those valgrind errors manually to find out if they're duplicate or not, or invalid or not. You should do it for them to narrow down the problem to code that actually might have a problem. It's part of the process of making a good bug report. Making good bug reports with Valgrind is hard unless you understand it well, RTFM, filter out the massive amount of false positives and then try again.

opensource drivers are trash, more at 11.

They're best thing that could ever happen in the computer world (just after GPL Linux). It seems you forgot about non graphic drivers, otherwise you wouldn't be writing such trash.

[DanL]

What are we yelling about! Loud Noises!

That was my 1,000th Phoronix forum post, and I used it just to make fun of your post. You should feel honored!

[mrugiero]

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.

[droste]

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.

[Garp]

As someone mentioned, libdrm does this if you build it with --enable-valgrind.

What are the negatives of doing this? Does it result in a slower library?