|
From: John R. <jr...@bi...> - 2019-05-16 14:35:10
|
>>> 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.
|