|
From: Florian K. <br...@ac...> - 2011-09-10 21:47:52
|
Hi,
I am looking at a case where valgrind reports:
ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 193 from 8)
but only one error is actually shown. I found that a bit confusing
because I expected 4 errors in the output. Is this by design?
If not then how about this:
Index: m_errormgr.c
===================================================================
--- m_errormgr.c (revision 12004)
+++ m_errormgr.c (working copy)
@@ -925,7 +925,7 @@
/* We only get here if not printing XML. */
VG_(umsg)("ERROR SUMMARY: "
"%d errors from %d contexts (suppressed: %d from %d)\n",
- n_errs_found, n_err_contexts,
+ n_errs_shown, n_err_contexts,
n_errs_suppressed, n_supp_contexts );
if (verbosity <= 1)
@@ -984,7 +984,7 @@
// the first printing
VG_(umsg)("ERROR SUMMARY: "
"%d errors from %d contexts (suppressed: %d from %d)\n",
- n_errs_found, n_err_contexts, n_errs_suppressed,
+ n_errs_shown, n_err_contexts, n_errs_suppressed,
n_supp_contexts );
}
|
|
From: Bart V. A. <bva...@ac...> - 2011-09-11 11:16:17
|
On Sat, Sep 10, 2011 at 11:47 PM, Florian Krohm <br...@ac...> wrote: > ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 193 from 8) > > but only one error is actually shown. I found that a bit confusing > because I expected 4 errors in the output. Is this by design? That's on purpose and should have been documented in the manual. The above output means that a certain error occurred four times. Valgrind only reports the first occurrence of each error though. Bart. |
|
From: Florian K. <br...@ac...> - 2011-09-11 14:30:49
|
On 09/11/2011 07:15 AM, Bart Van Assche wrote: > On Sat, Sep 10, 2011 at 11:47 PM, Florian Krohm <br...@ac...> wrote: >> ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 193 from 8) >> >> but only one error is actually shown. I found that a bit confusing >> because I expected 4 errors in the output. Is this by design? > > That's on purpose and should have been documented in the manual. The > above output means that a certain error occurred four times. Valgrind > only reports the first occurrence of each error though. > But shouldn't those errors that are not shown be counted as suppressed? Currently, they are not. Case in point is a valgrind report like this: ERROR SUMMARY: 9 errors from 3 contexts (suppressed: 0 from 0) with 3 errors actually shown. (I'm not making up this example for sake of argument.) If "suppressed" refers to only those errors not shown because of a suppression pattern then we ought to either change the total number of errors to the number actually shown or show the duplicates. ERROR SUMMARY: 9 errors from 3 contexts (suppressed: 0 from 0, duplicate: 6 from 3) But this might not be worth the effort. I really think the error summary should correctly some up what is shown in the report. Because that is what most people would expect. Florian |
|
From: Bart V. A. <bva...@ac...> - 2011-09-11 15:11:48
|
On Sun, Sep 11, 2011 at 4:30 PM, Florian Krohm <br...@ac...> wrote: > But shouldn't those errors that are not shown be counted as suppressed? No. In this context "suppressed" refers to "matching a suppression pattern". > Currently, they are not. Case in point is a valgrind report like this: > > ERROR SUMMARY: 9 errors from 3 contexts (suppressed: 0 from 0) > > with 3 errors actually shown. (I'm not making up this example for sake > of argument.) > If "suppressed" refers to only those errors not shown because of a > suppression pattern then we ought to either change the total number of > errors to the number actually shown or show the duplicates. > > ERROR SUMMARY: 9 errors from 3 contexts (suppressed: 0 from 0, > duplicate: 6 from 3) > > But this might not be worth the effort. I really think the error summary > should correctly some up what is shown in the report. Because that is > what most people would expect. All what I've found in the manual about error reporting is this (http://valgrind.org/docs/manual/manual-core.html): "Valgrind remembers all error reports. When an error is detected, it is compared against old reports, to see if it is a duplicate. If so, the error is noted, but no further commentary is emitted. This avoids you being swamped with bazillions of duplicate error reports." My preference is not to change Valgrind's output but instead to document clearly what the meaning is of the reported numbers. Bart. |
|
From: Florian K. <br...@ac...> - 2011-09-13 13:14:24
|
On 09/11/2011 11:11 AM, Bart Van Assche wrote:
> On Sun, Sep 11, 2011 at 4:30 PM, Florian Krohm <br...@ac...> wrote:
>
>> Case in point is a valgrind report like this:
>>
>> ERROR SUMMARY: 9 errors from 3 contexts (suppressed: 0 from 0)
>>
>> with 3 errors actually shown.
.. snip ..
>
> My preference is not to change Valgrind's output but instead to
> document clearly what the meaning is of the reported numbers.
To a user a report like the above looks wrong by any interpretation of
"suppressed". It violates the principle of least astonishment and should
be fixed. IMHO users don't gain a lot from knowing whether or not
valgrind found duplicate errors.
Florian
|
|
From: Julian S. <js...@ac...> - 2011-09-13 14:00:19
|
Well, (as Bart says), the documentation explains quite clearly that duplicate errors are not shown, and that the error summary tells you how often each error occurs. And this isn't the same as suppression of errors. > To a user a report like the above looks wrong by any interpretation of > "suppressed". It violates the principle of least astonishment and should > be fixed. I'd be inclined towards that more if we had mail / bug reports from users being confused in this regard, but I can't remember getting any. > IMHO users don't gain a lot from knowing whether or not > valgrind found duplicate errors. Hmm, I disagree. It can be useful to know which errors are occuring a lot and which are very rare. If you have a lot of different errors to deal with then this gives you at least some criterion for deciding which to look at first. J |
|
From: Florian K. <br...@ac...> - 2011-09-13 14:39:20
|
On 09/13/2011 10:00 AM, Julian Seward wrote: > > the error summary tells you how often each > error occurs. No, it doesn't. With 3 errors shown and a summary like this ERROR SUMMARY: 9 errors from 3 contexts (suppressed: 0 from 0) there is no way to tell how often any of the three errors occurred. >> IMHO users don't gain a lot from knowing whether or not >> valgrind found duplicate errors. > > Hmm, I disagree. It can be useful to know which errors are occuring a lot > and which are very rare. If you have a lot of different errors to deal with > then this gives you at least some criterion for deciding which to look at > first. > Yes, you're right. So, if I understand this correctly, you're saying counting duplicates and showing that in the summary is a good thing and we should do that. Right ? :) Florian |
|
From: Julian S. <js...@ac...> - 2011-09-13 14:55:38
|
On Tuesday, September 13, 2011 04:39:03 pm Florian Krohm wrote: > On 09/13/2011 10:00 AM, Julian Seward wrote: > > the error summary tells you how often each > > error occurs. > > No, it doesn't. With 3 errors shown and a summary like this > > ERROR SUMMARY: 9 errors from 3 contexts (suppressed: 0 from 0) > > there is no way to tell how often any of the three errors occurred. You can get the per-error counts with -v. > > Hmm, I disagree. It can be useful to know which errors are occuring a > > lot and which are very rare. If you have a lot of different errors to > > deal with then this gives you at least some criterion for deciding which > > to look at first. > > Yes, you're right. So, if I understand this correctly, you're saying > counting duplicates and showing that in the summary is a good thing and > we should do that. Right ? :) I'm saying I don't want to change how it is now, because I don't see any users complaining that it's confusing. Users complain about all manner of other stuff, but not (AFAIR, anyway) about this. J |