C++ Weekly - Ep 86 - Valgrind

hello and welcome to C++ weekly I'm your host Jason Turner I am an independent contractor and trainer now we've been talking again a lot about tools that help you catch errors in your C++ code and all of them so far with our sanitizers and our fuzzers have required some level of modifying your code to catch the error but I would now like to talk about vall grind which is a tool that is mostly for Linux but has been gaining support for other operating systems like Mac OS relatively recently or at least recently in my mind because I've been using it on Linux for a very long time now and what it can do is runtime memory error detection of your binary without requiring you to modify the source code at all or compile with any particular compiler flags or anything like that now keep in mind it is entirely possible for an optimization level to obscure an error but generally speaking you can get some really good results of fall ground so if you recall from our episode on sanitizers we've got this address sanitizer example that does an access passed the end of an array and we've got this uninitialized variable sanitizer example memory here that is almost certainly doing some sort of uninitialized read of a value so we are going to compile with no particular flags with no particular compiler let's start with the address example and it compiled it executes we don't see any errors from it but we can run it through vol grind and we can get this dump that tells us that we have done conditional jumps that dependent on uninitialized values and bad reads of memory and it gives us a considerable amount of information now we just just compiled without any debugging symbols abled so this makes it quite a bit harder to figure out what's going on but we can see that the compiler is trying to do things like string lane on uninitialized values so let's add some debugging and see if we can get maybe just a bit more information so you might notice how long it took to run and I'll point that out real quick this is an extremely small program that should take effectively zero seconds to execute running it through vol grind it's taking one and a half seconds to execute so we you axud expect something like a hundred times slowdown it can be absolutely ridiculous and absolutely unusable in some cases but it can give you this ability to test your program in ways that otherwise wouldn't be possible if you don't have access to the source code or you don't have access to a modern compiler that has sanitizer support but we can see basically that we're getting these errors starting on line seven of our program and you can see over and over again that line seven is clearly not doing good things so let's also look at our memory example which doesn't have as much going on so let's see if we can maybe get a more succinct error from it and we run this through of all grind and we can see on line 14 conditional move or jump depends on uninitialized values so just like the memory sanitizer for clang it is possible with they'll grind to say hey where did that memory actually get allocated that I am currently trying to access and that is enabled with the - - track origins equals yes option and by running that we can see it takes even longer to run we're at nearly two seconds now but we can see this uninitialized value was created by a stack allocation on line 11 so we get the exact same information we were able to get with the track origins option on claying with its memory sanitizer so this is an awesome tool I only just barely touched the surface of it here mem Tech is the default tool and we can see if we do - - tool equals we can pass it mem Tech or Hal grind there's a thread that the equivalent of the thread sanitizer and the memory and address sanitizer but there's also this tool called call grind which I find to be excellent and it gives you this kind of stable way of doing a test of the efficiency of your program and I know some people completely disagree with me as to how valuable this is but this told us effectively that two million one hundred ninety seven thousand instructions were executed in the execution of our program and if we were to compile it with optimizations enabled and take out the debug symbols and then rerun it with call grind we see a tiny slight difference because most of these instructions in the execution are actually the startup process of the C++ executable and loading the dynamic libraries and that kind of thing but this also gives us an interesting extra level of output that we have these call grind out files and they are tagged with the process number that the process was when it executed and it gives us all this information that shows us which functions were executed how many times and again this is not something that a human can really look at effectively but there is a really neat GUI tool for Linux called cake hash grind and it can take this output from call grind and I don't know if I can zoom the UI at all I don't appear to be able to but you can look and see all of the different functions that were executed during the execution of your program and this is an extremely mind-numbing ly simple example for what we're trying to show here because all of this is basically operating system things it's looking up all the dynamic libraries that a C++ program needs to launch with but anyhow check out K cache grind tech out call grind and vol grind and this is just another tool that you can put in your tool bag for debugging your C++ code be sure to subscribe follow me on Twitter and check out any of the links below you

Channel: Cᐩᐩ Weekly With Jason Turner

Views: 22,349

Rating: 4.9661016 out of 5

Keywords: C++, Programming

Id: 3l0BQs2ThTo

Length: 7min 38sec (458 seconds)

Published: Mon Oct 23 2017