
Valgrind Finds Thousands Of Potential Issues With Mesa [Phoronix] - rohshall
http://www.phoronix.com/scan.php?page=news_item&px=MTQzNjk
======
lysium
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
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
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).

------
cnvogel
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-
opti...](http://www.americanteeth.org/2013/08/14/valgrind-is-not-optional/))
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.

------
dmm
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.

------
pjmlp
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.

