Print less stats at the end of the run

[derekbruening]

From timurrrr@google.com on March 31, 2011 10:30:32

$ ./bin/drmemory.exe -batch -- ./tests/hello.exe
:::Dr.Memory::: ERRORS FOUND:
:::Dr.Memory::: 0 unique, 0 total unaddressable access(es)
:::Dr.Memory::: 0 unique, 0 total uninitialized access(es)
:::Dr.Memory::: 0 unique, 0 total invalid heap argument(s)
:::Dr.Memory::: 0 unique, 0 total warning(s)
:::Dr.Memory::: 0 unique, 0 total, 0 byte(s) of leak(s)
:::Dr.Memory::: 0 unique, 0 total, 0 byte(s) of possible leak(s)
:::Dr.Memory::: ERRORS IGNORED:
:::Dr.Memory::: 0 user-suppressed, 0 default-suppressed error(s)
:::Dr.Memory::: 0 user-suppressed, 2 default-suppressed leak(s)
:::Dr.Memory::: 3 ignored assumed-innocuous system leak(s)
:::Dr.Memory::: 137 still-reachable allocation(s)
:::Dr.Memory::: (re-run with "-show_reachable" for details)
:::Dr.Memory::: 0 error(s) beyond -report_max
:::Dr.Memory::: 0 leak(s) beyond -report_leak_max
:::Dr.Memory::: Details: C:\cygwin\home\timurrrr\drmemory\build_old/logs/DrMemory-hello.exe.3340.000/results.txt

From the user's perspective, half of this info is useless/redundant
a) One ":::Dr.Memory:::" prefix at the first line is probably enough
b) All the lines with "0 unique" are useless unless you explicitly set up the verbose mode
c) Add a "total errors: X unique, Y total" or something like that
d) Probably the whole "ERRORS IGNORED" section should go away unless we're in the verbose mode
e) Not sure if we need a full path to the details file.

WDYT?

Compare with:
$ ./bin/drmemory.exe -batch -- ./tests/hello.exe
Dr.Memory found errors: total 0
Full details can be found here: C:\cygwin\home\timurrrr\drmemory\build_old/logs/DrMemory-hello.exe.3340.000/results.txt

Original issue: http://code.google.com/p/drmemory/issues/detail?id=345

[derekbruening]

From bruen...@google.com on April 12, 2011 07:06:55

I disagree. Especially for a first-time or casual user of the tool, it's good to see the range of errors that were looked for, so the user knows he or she ran the tool correctly and that there isn't some runtime option that has to be turned on in order to check for leaks or something. If you're scripting the tool and don't want console output, use the -quiet option.

The prefix keeps the output separated from the app's output: there may be child processes so this is not just at the very end of a run.

The full path is critical: all the details are in the results file.

If the -report_max lines are not there, how would you know any kind of max was hit?

Better to have options to dial down and have the default be what a new user would want. I'm deliberately running a tool, I want info on what it did. We're not talking about thousands of lines (the callstacks are all in the results file), we're talking about a handful. I'm not a fan of having to turn on some verbose mode and re-run my entire application just to get a few lines of basic info.

Labels: -Priority-Medium Priority-Low

[derekbruening]

From bruen...@google.com on June 01, 2011 13:19:51

I could see shrinking the ERRORS IGNORED section.

for the ERRORS FOUND section, if a particular type is not being checked for, the resulting line should disappear: so -no_check_uninitialized should not print "0 uninitialized errors".

[derekbruening]

From bruen...@google.com on June 22, 2011 07:03:16

in r325 :
issue #345: do not report any info about errors that are not being checked

[derekbruening]

From derek.br...@gmail.com on September 02, 2011 12:06:59

This issue was closed by revision r498 .

Status: Fixed