|
From: Alex <zhi...@gm...> - 2019-05-16 15:01:57
|
On Thu, May 16, 2019 at 10:38 PM John Reiser <jr...@bi...> wrote:
> >>> then run `valgrind --leak-check=no --xml=yes --xml-file=x.xml ./main`
> >>>
> >>> check the x.xml file, we see:
> >>>
> >>> <error>
> >>> <unique>0x0</unique>
> >>> <tid>1</tid>
> >>> <kind>Leak_DefinitelyLost</kind>
> >>> <xwhat>
> >>> <text>10 bytes in 1 blocks are definitely lost in loss record 1
> of 1</text>
> >>> <leakedbytes>10</leakedbytes>
> >>> <leakedblocks>1</leakedblocks>
> >>> </xwhat>
>
> > This is not a bug, it is a feature.
> >
> > See the below code extracted from mc_main.c:
> > ...
> > /* If we've been asked to emit XML, mash around various other
> > options so as to constrain the output somewhat. */
> > if (VG_(clo_xml)) {
> > /* Extract as much info as possible from the leak checker. */
> > MC_(clo_leak_check) = LC_Full;
> > }
> > ...
> >
> > The idea is that if you use xml, it means that you have another tool
> > that extracts/shows/presents/... the information produced by Valgrind,
> > and so, the filtering of what the 'real end user' wants to see is
> > to be done by the xml tool, not anymore by Valgrind.
>
> The original poster has a point: --leak-check=full has a run-time cost,
> and the intent of --leak-check=no is to avoid that cost as much as
> possible. On a medium-to-large size program, just the presentation
> of the leak report can take several seconds, not even counting the cost
> of the [logical] garbage collection to compute the leak status,
> or possibly any per-allocation cost to preserve enough data to compute
> leaks.
> If the garbage collection involves demand paging using backing storage,
> then the cost can be large. An explicit --leak-check=no should
> override compiled-in assumptions about how much --xml-file= contains.
>
>
Yes, I agree with you about this. and thanks Philippe very much for
pointing this out. I will try to comment the option and to see if
everything goes well.
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|