Bug 186790 - Suppression pattern used for leaks are not reported
Summary: Suppression pattern used for leaks are not reported
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.4.1
Platform: unspecified Linux
: NOR normal
Target Milestone: blocking3.5.0
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-10 16:56 UTC by eguillot
Modified: 2009-08-07 21:55 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description eguillot 2009-03-10 16:56:44 UTC
When using suppression files with memcheck tool, all suppression patterns that have been used for memory errors suppression are listed when using otion "-v":
--10159-- supp:      1 Error 1
--10159-- supp:      2 dl_relocate_object
--10159-- supp:      1 strlen-not-intercepted-early-enough-HACK-3 

This is not the case for suppression patterns that apply to leaks.
No paragraph looking like that is logged.

This is quite annoying since the only way to find out if a suppression pattern is still useful is to remove it and run valgrind again...

Julian considered it as a regression and he expected the behaviour was the same for both memory errors and memory leaks.

Best regards
Comment 1 Julian Seward 2009-05-06 11:09:35 UTC
I should say first of all, that this bug is more serious than it
first appears.  It makes it impossibly to use the list of used
suppressions to reliably "debug" suppressions files, which is a
problem in large projects.

The bug is unfortunately the result of a design problem (or, really
lack of properly thought-out design) in our error management code
and how it interacts with Memcheck.  Problem happens because the
used-suppressions list is printed out before Memcheck's leak checker
runs (sigh).  So, although the leak checker does make a note of 
which suppressions it uses, it does so too late.

It's trivially fixed: in m_main.c, function shutdown_actions_NORETURN,
there are the following lines (m_main.c:2156 in the 3.4.1 sources):

   if (VG_(needs).core_errors || VG_(needs).tool_errors)
      VG_(show_all_errors)();

   VG_TDICT_CALL(tool_fini, 0/*exitcode*/);

If you change this to be the other way round, then the behaviour is as
you want:

   VG_TDICT_CALL(tool_fini, 0/*exitcode*/);

   if (VG_(needs).core_errors || VG_(needs).tool_errors)
      VG_(show_all_errors)();

Unfortunately this causes the lines of text that Memcheck prints at
the end, to be in a different order.  The XML output is unchanged.

There is no way to fix this properly without changing the order of output
from Memcheck (in text-mode output).  IMO this needs properly redesigning
in 3.5.x.
Comment 2 Nicholas Nethercote 2009-05-07 04:01:23 UTC
I don't think changing the order of Memcheck's output is a problem.
Comment 3 Nicholas Nethercote 2009-07-15 08:57:54 UTC
To clarify:  if the change in comment 2 is done, it will put Memcheck's LEAK SUMMARY before the ERROR SUMMARY.  This is not necessarily a bad thing;  currently leaks aren't really counted as errors but perhaps they should be -- eg. see bug 152393.  (As well as this bug, of course.)

It might also make sense to give tools control over calling VG_(show_all_errors)().
Comment 4 Julian Seward 2009-08-07 21:55:32 UTC
Well, I believe this is fixed, finally.  svn revs 10746-10749.
Fix will be in 3.5.0.