|
From: Jeremy F. <je...@go...> - 2005-02-25 21:49:05
|
Nicholas Nethercote wrote:
> - make --leak-check=yes the default for Memcheck
Maybe. For simply running a program its a good default, but running a
shell script (with lots of exits) can be hit quite hard by --leak-check
(though its a bit more efficient now). Also, if a program is using
DO_LEAK_CHECK, they might not want an implicit one too.
> - increase the default --num-callers size to 12
Yes! I was about to propose this. 4 has been way too small for a long
time. Also, the default --leak-resolution=low (2 frames matches) is too
low as well; I think it should default to "med".
And should we consider defaulting to memcheck again?
> And I think that's most useful because the survey responses I've
> received in the last year (14 of them) almost everyone uses
> --leak-check=yes all the time, and most people immediately crank up
> --num-callers to at least 10 (and sometimes much higher, eg. 40).
> --show-reachable=yes is also pretty popular, but I don't think it's
> quite popular enough to make the default.
I find --show-reachable is too noisy for common use.
> So, the quick start would then be shorter, since I wouldn't have to
> explain those options. I think it's currently already too long, but
> it's only a draft.
>
> I think this document and these settings changes would lower the bar
> for new users to get Memcheck working usefully as quickly as possible,
> which is what 95% of users would want, and is something we should aim
> for.
>
> Comments?
>
> N
>
>------------------------------------------------------------------------
>
>Valgrind quick start
>--------------------
>This document contains the minimum information you should know to start
>detecting memory errors in your program with Valgrind.
>
>The Valgrind distribution has multiple tools. The memory checking tool
>(called Memcheck) can detect many common memory errors such as:
>
>- touching memory you shouldn't (eg. overrunning heap block boundaries)
>- using values before they have been initialized
>- incorrect freeing of memory, such as double-freeing heap blocks
>- memory leaks
>
>Here's how to use it.
>
>1. Preparing your program. Compile your program with debugging information so
>that Memcheck's error messages include exact line numbers.
>
>
I'd add "(-g)" after "debugging information", just to be explicit.
>2. Running your program under Memcheck. If you normally run your program
>like this:
>
> myprog arg1 arg2 arg3
>
>Use this command line:
>
> valgrind --tool=memcheck --num-callers=40 --leak-check=yes myprog arg2 arg2 arg3
>
>The --tool option invokes Memcheck. The --num-callers option asks for big
>stack traces, which make error messages more informative. The --leak-check
>option turns on the memory leak detector.
>
>Your program will run much slower (eg. 20 to 30 times) than normal.
>Memcheck will describe any errors it detects. When your program terminates,
>Memcheck will describe any memory leaks it detects.
>
>3. Interpreting Memcheck's output. Here's an example C program with two
>memory errors.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int f(void)
> {
> int* x = malloc(10 * sizeof(int));
> x[10] = 0; // problem 1: heap block overrun
> return; // problem 2: memory leak -- x not freed
> }
>
> int main(void)
> {
> f();
> return 0;
> }
>
>Most error messages look like the following, which describes problem 1, the
>heap block overrun:
>
> ==19182== Invalid write of size 4
> ==19182== at 0x804838F: f (a.c:8)
> ==19182== by 0x80483AB: main (a.c:14)
> ==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd
> ==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)
> ==19182== by 0x8048385: f (a.c:7)
> ==19182== by 0x80483AB: main (a.c:14)
>
>Things to notice:
>- There is a lot of information in each error message; read it carefully.
>
>- The 19182 is the process ID; it's usually unimportant.
>
>- The first line ("Invalid write...") tells you what the error is. Here,
> the program wrote to some memory it should not have due to a heap block
> overrun.
>
>- Below the first line is a stack trace. Stack traces can get quite large,
> and be confusing, especially if you are using the C++ STL. Reading them
> from the bottom up can help. If the stack trace is not big enough, use a
> bigger --num-callers option.
>
>- The addresses (eg. 0x804838F) are usually unimportant, but occasionally
> crucial for tracking down weirder bugs.
>
>- Some error messages, such as this one, have a second component which
> describes the memory address involved, and possibly give another stack
> trace showing where it was allocated or freed.
>
>
I would explicitly, but briefly, describe the Address block.
Looks good.
J
|