Bug 201170

Summary:	Want --show-possible option so I can ignore the bazillion "possibly leaked" warnings
Product:	[Developer tools] valgrind	Reporter:	Dan Kegel <dank>
Component:	memcheck	Assignee:	Nicholas Nethercote <njn>
Status:	RESOLVED FIXED
Severity:	normal	CC:	bart.vanassche+kde, jseward, njn
Priority:	NOR
Version:	unspecified
Target Milestone:	wanted3.6.0
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Patch to implement proposed option second draft of patch including doc and test Rediffed as of r10904 or so

Description Dan Kegel 2009-07-23 00:50:40 UTC

Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

Valgrinding the chromium UI tests generates something like
a gigabyte of XML logs from valgrind, nearly 100% of which
is "possibly lost" leaks.  Now, XML is a highly efficient
format, designed for rapid parsing :-), and I have a very fast
CPU, but still my python script seems to be spending ten
minutes parsing all that output.
I find myself craving a --show-possible option.  It would default
to yes to match current behavior.  Setting it to "no"
would match chromium's current needs, and would
let me avoid having to rewrite our xml to be ten times faster.

Why there are so many "possibly leaked" blocks is another
question, but hey, one thing at a time.

Comment 1 Dan Kegel 2009-07-23 01:36:36 UTC

Looks easy, I hope to have a patch soon.

Comment 2 Dan Kegel 2009-07-23 02:12:34 UTC

Created attachment 35559 [details]
Patch to implement proposed option

Gee, that was easy.

Comment 3 Nicholas Nethercote 2009-07-23 02:34:11 UTC

(In reply to comment #2)
> 
> Gee, that was easy.

Yeah :)

Comment 4 Nicholas Nethercote 2009-07-23 02:37:37 UTC

Actually, if you include a test that will help.  Copy memcheck/tests/leak-check-full and add --show-possible=yes to its .vgtest.  Output should be the same as leak-check-full.stderr.exp minus the possible errors.

Oh, and updating the docs and usage message is necessary too!

Comment 5 Dan Kegel 2009-07-28 20:42:38 UTC

Created attachment 35705 [details]
second draft of patch including doc and test

OK, here's a second try, with doc and tests.  Did I miss anything?

Also, in my experience, the "possibly lost" reports aren't
very useful.  Is this the case for others as well?  If so,
maybe we should make the default be "no".

Comment 6 Dan Kegel 2009-09-05 21:59:48 UTC

ping.  Seems to work well for me.  What's left before this can be applied?

Comment 7 Nicholas Nethercote 2009-09-05 22:12:21 UTC

Just the usual developer time to evaluate it.  And with 3.5.0 having taken a lot of work recently I'm working on other things for a while.

Comment 8 Dan Kegel 2009-11-09 19:55:46 UTC

Created attachment 38212 [details]
Rediffed as of r10904 or so

Comment 9 Julian Seward 2010-02-21 14:30:31 UTC

+1 for this, with the minor proviso of changing the flag
name to --show-possibly-lost since --show-possible is very unspecific

Comment 10 Bart Van Assche 2010-08-26 12:53:45 UTC

(In reply to comment #9)
> +1 for this, with the minor proviso of changing the flag
> name to --show-possibly-lost since --show-possible is very unspecific

Added in r11292.