3 ms·

Valgrind Finds Thousands Of Potential Issues With Mesa [Phoronix]

14 points by rohshall 13y ago

lysium 13y ago
While valgrind finds issues, it's totally unclear if these issues are serious. The explanation of the Mesa developer that responded sounds reasonable (valgrind cannot track past ioctl). I'm wondering, if this article is more about valgrind than about Mesa: what does it help if only a fraction of the reported issues is an actual issue?
- merijnv 13y ago
  Valgrind supports suppression of reports, if valgrind can't track past ioctl, they should add a suppression file to their repo that supresses these warnings, making valgrind output useful again.
forgottenpaswrd 13y ago
Well, most of the valgrind errors should be repetitions, so I would say there are probably 5000 error or so. It is a great idea to use Valgrind or other automatic tools(we make our own), but it is really hard when you had already developed a project without it. Going from 507,326 errors to 507,325 or 507,310 is not very motivating(0.000029% progress).
pjmlp 13y ago
The joys of safety when using C. Validation tools and warnings as errors are not optional when using C and its derivatives (Obj-C/C++). Not everyone is an elite C developer and even those can make mistakes.
dmm 13y ago
This is completely a non-story. If you're going to write a blog entry about a project's valgrind results at least track down one of the reports that's actually a bug.
cnvogel 13y ago
It's a little unfortunate that the author did not at least try to hunt down a few of them and present a conlclusion about if the warnings are benign or serious. I don't have the exact version of Mesa that the blog-post (http://www.americanteeth.org/2013/08/14/valgrind-is-not-optional/ http://www.americanteeth.org/2013/08/14/valgrind-is-not-opti...) seems to refer to. But the first two functions in the i965 driver code that valgrind complained about basically do something like the following code: uint32_t *surf = brw_state_batch(...) surf[0] = ...stuff with flags for the GPU-code... (...) surf[5] = ...even more stuff, encoding coordinates and so on... (...) Unfortunately that pointer "*surf" seems to be allocated by some batch-buffer-memory allocation magic, so (after only greping through the source for 5 minutes) I would not be able to conclude if it's a fake warning (maybe refering to some memory that is allocated by some DRI kernel interface mmap-magic) or indeed serious (say, a mistake when calculating the proper boundaries of allocated pages). But with a library used as regularly as Mesa I'd give the authors the benefit of doubt and guess that to detect the subtle errors, one would first have to educate valgrind about that DRI-specific way of allocating memory.

14 points by rohshall 13y ago

While valgrind finds issues, it's totally unclear if these issues are serious. The explanation of the Mesa developer that responded sounds reasonable (valgrind cannot track past ioctl). I'm wondering, if this article is more about valgrind than about Mesa: what does it help if only a fraction of the reported issues is an actual issue?

merijnv 13y ago
Valgrind supports suppression of reports, if valgrind can't track past ioctl, they should add a suppression file to their repo that supresses these warnings, making valgrind output useful again.

forgottenpaswrd 13y ago

Well, most of the valgrind errors should be repetitions, so I would say there are probably 5000 error or so. It is a great idea to use Valgrind or other automatic tools(we make our own), but it is really hard when you had already developed a project without it. Going from 507,326 errors to 507,325 or 507,310 is not very motivating(0.000029% progress).

pjmlp 13y ago

The joys of safety when using C. Validation tools and warnings as errors are not optional when using C and its derivatives (Obj-C/C++). Not everyone is an elite C developer and even those can make mistakes.

dmm 13y ago

This is completely a non-story. If you're going to write a blog entry about a project's valgrind results at least track down one of the reports that's actually a bug.

cnvogel 13y ago

It's a little unfortunate that the author did not at least try to hunt down a few of them and present a conlclusion about if the warnings are benign or serious. I don't have the exact version of Mesa that the blog-post (http://www.americanteeth.org/2013/08/14/valgrind-is-not-optional/ http://www.americanteeth.org/2013/08/14/valgrind-is-not-opti...) seems to refer to. But the first two functions in the i965 driver code that valgrind complained about basically do something like the following code: uint32_t *surf = brw_state_batch(...) surf[0] = ...stuff with flags for the GPU-code... (...) surf[5] = ...even more stuff, encoding coordinates and so on... (...) Unfortunately that pointer "*surf" seems to be allocated by some batch-buffer-memory allocation magic, so (after only greping through the source for 5 minutes) I would not be able to conclude if it's a fake warning (maybe refering to some memory that is allocated by some DRI kernel interface mmap-magic) or indeed serious (say, a mistake when calculating the proper boundaries of allocated pages). But with a library used as regularly as Mesa I'd give the authors the benefit of doubt and guess that to detect the subtle errors, one would first have to educate valgrind about that DRI-specific way of allocating memory.