Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 26

Thread: Valgrind Finds Thousands Of Potential Issues With Mesa

  1. #11
    Join Date
    Jul 2010
    Posts
    483

    Default

    Quote Originally Posted by chrisb View Post
    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.

  2. #12
    Join Date
    Mar 2011
    Posts
    327

    Default

    Quote Originally Posted by Cyborg16 View Post
    This article is seriously confusing.

    Valgrind can (and frequently does) report one issue many times, which is probably the main reason the number is so big. I understand no more from it than "valgrind has found some issues".

    Secondly, as pointed out, valgrind does report false positives.

    Yes, they should probably be checked, but why the hell make a big deal of it like something major is up? Especially when you don't understand what it's about?

    I know there's a bit of trolling on these forums but sometimes it seems Michael acts like a troll too...
    +1

    I remember valgrind having fits with threads before. It would rack up errors every time a thread was merged or destroyed. It's actually one of the reasons I went to virtual timers.

  3. #13

    Default

    libdrm needs to be compiled with --enable-valgrind to suppress these warnings. Film at 11.

  4. #14
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,876

    Default

    Quote Originally Posted by ickle View Post
    libdrm needs to be compiled with --enable-valgrind to suppress these warnings. Film at 11.
    Such sass! For a moment I had to check to make sure I wasn't on Tumblr

  5. #15
    Join Date
    May 2009
    Posts
    30

    Default

    Quote Originally Posted by Cyborg16 View Post
    I know there's a bit of trolling on these forums but sometimes it seems Michael acts like a troll too...
    Sometimes? I've reached the stage of generally assuming that's what is going on with all these Linkbait titles and melodramatic ZOMG THE SKY IS FALLING!!!!1111oneoneone articles.

  6. #16
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    133

    Default

    Quote Originally Posted by peppercats View Post
    opensource drivers are trash, more at 11.
    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.

  7. #17
    Join Date
    May 2009
    Posts
    30

    Default

    Quote Originally Posted by Kayden View Post
    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?

  8. #18
    Join Date
    Jul 2009
    Location
    Germany
    Posts
    486

    Default

    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.

  9. #19
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by dh04000 View Post
    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.

  10. #20
    Join Date
    Oct 2007
    Posts
    1,268

    Default

    Quote Originally Posted by dh04000 View Post
    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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •