Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 6 of 6
  1. #1
    Regular Coder mlse's Avatar
    Join Date
    Mar 2005
    Posts
    624
    Thanks
    20
    Thanked 19 Times in 18 Posts

    Thumbs up Valgrind --- its great!

    Hi all,

    I've just starting writing C++ again on Linux after a long break. Having gotten comfortably used to the way in which PHP leads you by the hand through everything; going back to C++ was something of a shock!

    Anyway, I got pissed off with gdb and it's really useless debugging information and so I found this: http://valgrind.org/

    It is the best debugging tool that I have ever found for Linux! I haven't used the visual front-end (Valkyrie) yet, but the Valgrind tool itself is great! It effectively provides a complete VM for your C++ to run on and keeps tabs on all your memory allocations and will warn you, for example, if you are overruning the end of an array, even if the code does not crash. I think it even handles multi-threaded stuff (for example it will, I think, tell you exactly where, why and how a race condition is occuring).

    I hope that is useful to someone! Its speeded up my development time immeasurably - no more trying to figure out exactly where that infuriating segmentation violation is occurring ...
    Last edited by mlse; 06-15-2007 at 01:50 PM.

  • #2
    Regular Coder mlse's Avatar
    Join Date
    Mar 2005
    Posts
    624
    Thanks
    20
    Thanked 19 Times in 18 Posts
    Additional: Having just upgraded to Debian 4.0 (Etch), I've discovered that it is available as a precompiled package ... apt-get install valgrind is all that's required

  • #3
    Regular Coder ralph l mayo's Avatar
    Join Date
    Nov 2005
    Posts
    951
    Thanks
    1
    Thanked 31 Times in 29 Posts
    valgrind is a great tool, combined with gdb. I also use electric fence, as it's a lot faster and it tends to pick up the same stuff as valgrind without giving me as much spurious junk about builtins that there's no helping.

    Don't forget to turn on debugging symbols (-g) and turn off optimizations when compiling for any debugger. The flags I usually use for quality control are
    Code:
    -Wall -Wextra -Wshadow -pedantic -g3 -O0 -lefence
    -O0 implies -fno-inline, which makes the call stack explicit to avoid a bit of potential confusion looking at traces.

    edit: gprof is also pretty great for profiling, just compile with -pg (and without -lefence), run the executable to generate statistics and use gprof <executable name> to get the breakdown. Unfortunately for C++ you almost have to use a post-processor because you will find yourself looking at pages and pages of template crap. Something like kprof truncates that stuff and organizes everything usefully.

    Also in the way of C[++] dev tools there's mudflap for hunting down overflow violations, but I haven't really bothered with it because the documentation is poor and I can't figure out how to suppress the many pages of spurious errors having to do with things like <vector> internals it reports for even simple programs.
    Last edited by ralph l mayo; 07-08-2007 at 01:53 AM.

  • #4
    Regular Coder mlse's Avatar
    Join Date
    Mar 2005
    Posts
    624
    Thanks
    20
    Thanked 19 Times in 18 Posts
    I hadn't heard of electic fence, sounds better without the builtin stuff, although I think valgrind's good for me and I *think* you can turn off builtin stack trace with one of the options ... haven't rummaged through the help for it yet though!

    Another of my favorite compiler flags for cross-platform stuff has got be -ansi

    Incidentally, can you force electric fence ouput as XML? I really like that feature of valgrind.

  • #5
    Regular Coder ralph l mayo's Avatar
    Join Date
    Nov 2005
    Posts
    951
    Thanks
    1
    Thanked 31 Times in 29 Posts
    Nah, no XML.. electric fence is very low frills. Like the name implies it's a memory guard, and the extent of its reporting is dumping core when something dodgy you do trespasses on the bounds it sets around allocated memory. It's really not a replacement for valgrind but it's fast enough to stick in any old compilation, whereas I hit valgrind usually only at major development waypoints since it's sooo slow :/

  • #6
    Senior Coder
    Join Date
    Apr 2003
    Location
    England
    Posts
    1,192
    Thanks
    5
    Thanked 13 Times in 13 Posts
    My only problem with valgrind is that it tells me about problems with the libraries I am using, which makes it hard to find which problems are in my code. I will have to try that electric fence thing.

    For some reason I never use debuggers. I seem to always be able to just see the error and where it is happening and then stare at the code until it gets fixed , even on large projects Stack traces are very useful things.


  •  

    Posting Permissions

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