Is valgrind always right?

This is a discussion on Is valgrind always right? within the Linux Programming forums, part of the Platform Specific Boards category; I used valgrind to check for memory leaks. When I checked my application with "--leak-check=full --show-reachable=yes -v", it showed tons ...

  1. #1
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476

    Is valgrind always right?

    I used valgrind to check for memory leaks. When I checked my application with "--leak-check=full --show-reachable=yes -v", it showed tons of errors. However when I looked at the error verbose message, it showed that the ones causing the leak is not my application, but the libraries I was using. Eg, I used SDL for the graphics and CUPS for printing. Valgrind showed a leak on the "SDL_Init()" line from my application. But I am certain that I called "SDL_Quit()" in the destructor of my application. And valgrind not only showed one error from this SDL_Init() line, but many. So valgrind showed approximately 10 message of errors from this line. The same applies to the CUPS library. I made a class to manage the printing. In its constructor, I called cupsGetDests() and store the result to a private member. And in the destructor, I called cupsFreeDests() to free that variable. But valgrind showed a bunch of errors from the "cupsGetDests()" line. Why does this happen?

    Thanks in advance.
    ERROR: Brain not found. Please insert a new brain!

    “Do nothing which is of no use.” - Miyamoto Musashi.

  2. #2
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,452
    Have you tried a small test application like
    Code:
    int main()
    {
    SDL_Init();
    SDL_Quit();
    return 0;
    }
    ??

    Some leaks are reported just because you THINK you called the quit - but actually it was not called on some reason...

    So make a small test with the call to problematic function only and see if it has leaks...
    If it has - you can ignore them in the report build for your own application (while you do not call Init/Quit repeatedly in the lifecycle of the application)
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  3. #3
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    There was this post to the SDL newsgroup last month. I have no idea if that applies to your program or not. (Try the minimal, like vart sugggested.)

    Just reminded me of it.
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  4. #4
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    Yeah, it's still there. In fact there's also an error report in SDL_SetVideoMode() line. So, I think it's not my fault after all. Thanks again guys.
    ERROR: Brain not found. Please insert a new brain!

    “Do nothing which is of no use.” - Miyamoto Musashi.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. erors from Valgrind ,,
    By prakash0104 in forum C Programming
    Replies: 2
    Last Post: 04-05-2009, 07:33 PM
  2. Makefiles, GCC's -ggdb option, and Valgrind
    By Jesdisciple in forum C Programming
    Replies: 5
    Last Post: 03-14-2009, 04:25 PM
  3. Bug hunting with Valgrind
    By Smjert in forum C Programming
    Replies: 8
    Last Post: 11-06-2008, 03:21 AM
  4. Replies: 1
    Last Post: 12-01-2007, 01:06 AM
  5. Valgrind output
    By m_larkin2001 in forum C++ Programming
    Replies: 1
    Last Post: 06-09-2006, 02:28 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21