Announcement

Collapse
No announcement yet.

Valgrind Finds Thousands Of Potential Issues With Mesa

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

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


            • #21
              Originally posted by peppercats View Post
              opensource drivers are trash, more at 11.
              They're best thing that could ever happen in the computer world (just after GPL Linux). It seems you forgot about non graphic drivers, otherwise you wouldn't be writing such trash.

              Comment


              • #22
                I used to think that all Valgrind errors were bugs too..
                Until I started running valgrind on the popular GNU tools like ps, ls, top, etc and found Valgrind errors that appeared to be memory leaks.

                Turned out, that Valgrind was complaining about some memory that wasn't explicitly being freed in code, but it doesn't matter because the memory is automatically freed when the process terminates. Adding code to explicitly free that memory would do nothing but delay the process's termination of a process that's ready to terminate, so the bug reports were closed and I learned to take Valgrind problems a lot less seriously.

                Valgrind is useful in tracking down problems when you know there is a problem, but can also generate a massive amount of false positives and the few positives that it does have will often be multipled by 10,000x for the same line of code.

                Edit: And also as mentioned, the kernel has got IO controlls that work with memory in ways that Valgrind doesn't know about / understand properly and so will result in a large number of false positives.. You need to filter out all the possible false positives from the ioctrls first, otherwise you're not really helping much. There's no way a dev is going to go through all those valgrind errors manually to find out if they're duplicate or not, or invalid or not. You should do it for them to narrow down the problem to code that actually might have a problem. It's part of the process of making a good bug report. Making good bug reports with Valgrind is hard unless you understand it well, RTFM, filter out the massive amount of false positives and then try again.
                Last edited by Sidicas; 08-15-2013, 03:25 AM.

                Comment


                • #23
                  Clang Static Analyzer and Valgrind are two solid tools to flush out the bugs.

                  Comment


                  • #24
                    eeh, after spending much time going over Mesa code, I think most of this comes from the over-abundant upcasting and slicing in the Mesa code base. GL is a really tricky beast to wrangle.

                    Comment


                    • #25
                      Originally posted by peppercats View Post
                      opensource drivers are trash, more at 11.
                      Drivers are trash.

                      Comment


                      • #26
                        Originally posted by WorBlux View Post
                        Drivers are trash.
                        Trash is trash. Trash.

                        But seriously. Trash.

                        I hope they don't ban me. Trash trash trash.

                        Comment

                        Working...
                        X