Bug 186790

Summary:	Suppression pattern used for leaks are not reported
Product:	[Developer tools] valgrind	Reporter:	eguillot
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	RESOLVED FIXED
Severity:	normal	CC:	glider, njn, timurrrr
Priority:	NOR
Version First Reported In:	3.4.1
Target Milestone:	blocking3.5.0
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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.