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.
Looks easy, I hope to have a patch soon.
Created attachment 35559 [details] Patch to implement proposed option Gee, that was easy.
(In reply to comment #2) > > Gee, that was easy. Yeah :)
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!
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".
ping. Seems to work well for me. What's left before this can be applied?
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.
Created attachment 38212 [details] Rediffed as of r10904 or so
+1 for this, with the minor proviso of changing the flag name to --show-possibly-lost since --show-possible is very unspecific
(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.