|
From: Philippe W. <phi...@sk...> - 2019-05-15 22:17:44
|
On Wed, 2019-05-15 at 13:41 +0800, Alex wrote:
> is anyone here?
>
> On Tue, May 14, 2019 at 6:55 PM Alex <zhi...@gm...> wrote:
> > we have have the simple code like this:
> >
> > #include <stdlib.h>
> > int main(int argc, char *argv[])
> > {
> > malloc(10);
> > return 0;
> > }
> >
> > 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 user manual (e.g. the paragraph that describes --leak-check option
should however describe this behaviour ...
Philippe
|