Valgrind Finds Thousands Of Potential Issues With Mesa
While not meaning to rant about Mesa or focus upon the project exclusively, a Fedora contributor, Casey Dahlin, has pointed out the shocking number of potential memory issues within Mesa as found by Valgrind, the important open-source programming tool for memory debugging, profiling, leak detection, and other memory-related matters.
In the development of Luftballoons, a open-source software suite for 3D game production, Casey Dahlin has been dealing with Valgrind in tracking down use-after-free bugs and is encouraging more developers to use the programming tool. He feels Valgrind should not be an option but more or less expected to be used by open-source developers.
While not all of the Valgrind-spotted errors may be relevant, the GPL program has found thousands (or 507,326 errors from 743 contexts to be exact) with the open-source Mesa graphics library. Casey has shared details in this blog post. Even if only a portion of the Valgrind spotted problems are legitimate, that's still thousands of potential memory problems with Mesa.
Casey Dahlin ended with, "Again I can't pick on the Mesa devs too much, but as a general rule, if you are writing a C project, valgrind is not optional, released code should generate no valgrind errors, and in the case of an exception or valgrind bug, you should ship a suppression file. With the great power of a low level language comes great responsibility, and this simple and easy acceptance test finds many dangerous errors. Valgrind is about the fourth tool that has broken on me trying to find this bug (surge of GDB bug reports to come soon). Now I'm sitting here trying to determine if hunting a few of these errors constitutes good citizenship or a dangerous slide into yak shaving. I guess it's ironic that it's my own memory mismanagement defect that's causing all the effort. No rest for the wicked I suppose."
David Airlie has been the only Mesa contributor to respond to the Mesa Valgrind posting yet and he suggests some of the errors may be due to kernel ioctls not known by Valgrind. "We access a lot of kernel data via ioctls that valgrind doesn't understand. I'm not saying that is definitely the case but it was in a lot of places."
Those wanting to do memory profiling on their code-bases should stop by Valgrind.org for this great tool.