Announcement

Collapse
No announcement yet.

Valgrind Finds Thousands Of Potential Issues With Mesa

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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.

    Comment


    • #12
      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.

      Comment


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

        Comment


        • #14
          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
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #15
            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.

            Comment


            • #16
              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.
              Free Software Developer .:. Mesa and Xorg
              Opinions expressed in these forum posts are my own.

              Comment


              • #17
                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?

                Comment


                • #18
                  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.

                  Comment


                  • #19
                    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.

                    Comment


                    • #20
                      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!

                      Comment

                      Working...
                      X