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: | 3.4.1 | ||
Target Milestone: | blocking3.5.0 | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
eguillot
2009-03-10 16:56:44 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. I don't think changing the order of Memcheck's output is a problem. 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)(). Well, I believe this is fixed, finally. svn revs 10746-10749. Fix will be in 3.5.0. |