|
From: Ashley P. <as...@pi...> - 2009-08-13 15:14:49
|
Hi,
I've been testing the xml output of valgrind and the new options since
the merge. I've recently returned from holiday and have read several
discussions on the mailing lists but thought it might be appropriate to
start a new thread.
Points I've spotted are:
a) Why do we still need --xml=yes, isn't it implied by
--xml-file=<file>? It would appear the --xml=yes option can be dropped
completely, if used without a XML output destination it aborts anyway.
In addition the error is reported to the user twice, in different
formats.
ashley@alpha:/mnt/memfs/val-install/bin$ ./valgrind --xml=yes ls
==18750== --xml=yes has been specified, but there is no XML output
==18750== destination. You must specify an XML output destination
==18750== using --xml-fd=, --xml-file= or --xml=socket=.
valgrind: Bad option '--xml=yes, but no XML destination specified';
aborting.
valgrind: Use --help for more information.
ashley@alpha:/mnt/memfs/val-install/bin$
b) If I do specify --xml-file=<file> but not --xml=yes I get partial
output in the xml file.
ashley@alpha:/mnt/memfs/val-install/bin$ ./valgrind --xml-file=x
--log-file=l ls
callgrind_annotate cg_annotate l no_op_client_for_valgrind
valgrind-listener
callgrind_control cg_merge ms_print valgrind x
ashley@alpha:/mnt/memfs/val-install/bin$ cat x
<errorcounts>
</errorcounts>
ashley@alpha:/mnt/memfs/val-install/bin$
c) It doesn't seem to be possible to get both the XML output and the
standard output. I realise it wasn't before but when I read on the list
that it was it struck me as a good idea. More on this later.
d) I like the idea of having separate streams for XML and serious error
messages, ideally these would also be encapsulated in the xml but in
practice they are rare enough to get away without this. I'd like to use
--xml-socket= --log-socket= to catch the output of multiple processes
simultaneously however there would be no way to identify which process
any output on a non-xml socket came from.
e) There is no way to get a "qualifier" over a xml socket.
f) Using log file qualifiers with XML results in the xml for the
qualifier being put to stdout
ashley@alpha:/mnt/memfs/val-install/bin$ ./valgrind --xml-file=x.%q{ID}
--xml=yes ls
==18777== <logfilequalifier> <var>ID</var> <value>0</value>
</logfilequalifier>
callgrind_annotate cg_annotate l no_op_client_for_valgrind
valgrind-listener
callgrind_control cg_merge ms_print valgrind x.0
g) The "Command:" <line> in the xml preamble is superfluous.
All these tests are preformed with the head (10800M), the diffs all
relate to VPATH building.
With regard to c) one of the tests I did before was to try to
re-construct the normal output from the xml output (it's a very good way
of testing the xml parsing), previously I've always just run the
application twice, once in each mode however this limits the type of
application you can test.
I was wondering if would be possible to change the tests to use
something like this, have the test suite check that 1) the xml output
can be used to re-create the normal output, byte-for-btye and 2) the xml
output matches the expected xml for that test. For this you'd need to
re-write the "expected output" files in some new kind of xml but that
shouldn't be too hard, all it would need to say was which fields of
output needed to match (function names, error types) and which didn't
(line numbers).
Ashley,
--
Ashley Pittman, Bath, UK.
Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk
|