|
From: Julian S. <js...@ac...> - 2009-05-13 11:13:04
|
Hi,
I've been mulling over some changes in how V emits output. It
seems to me the output systems are in need of an overhaul, to
fix various problems.
(1) XML output on its own file descriptor.
With --xml=yes, Memcheck can produce output in XML form,
which is useful for GUI writers, as it produces output in a
stable, easily parsed form. However, there have been various
complaints about the implementation. Specifically, XML
output goes on the same file descriptor as the "normal"
output. This has two bad effects:
- it means all other obscure warning messages that Valgrind
might occasionally emit (eg, to say that debuginfo for
XYZ.so is corrupt, or whatever) can't be emitted, since
this would screw up the XML. This is highly inconvenient,
and hides potentially important messages.
- despite the above, some messages do get through, hence
breaking XML parsers and generally giving the GUI writers
lots of hassle. Eg
https://bugs.kde.org/show_bug.cgi?id=191067
The obvious fix is to have XML go on its own file descriptor,
so there are now two output channels which don't interfere.
--xml=yes still controls whether a tool does XML or text output
--log-fd=, --log-file= and --log-socket= retain their existing
behaviour
--xml=fd=, --xml-file= and --xml-socket= are added. These
specify the XML output channel.
One advantage is that "normal" text-mode users will see no
difference. For GUI writers, the use of --log-file= will
need to change to --xml-file=, but that's no big deal.
These changes are already present in branches/MESSAGING_TIDYUP.
(2) Behaviour of VG_(message)
Also in branches/MESSAGING_TIDYUP, VG_(message) has been made
to behave more like printf. It no longer automatically
prints a \n at the end of the message, and multiple calls can
be used to build up a single-line message, without the
==PID== preamble being printed multiple times. Finally, a
single call to VG_(message) that prints a message with
multiple \ns will result in ==PID== preambles being printed
in the right places.
The old behaviour isn't a problem per se, but it is an
annoying inconsistency, which makes it harder to do XML
output cleanly.
(3) Behaviour of -v
-v makes the text output more verbose. It is used for a
variety of purposes which need to be split up:
(a) printing informative lines, eg when debuginfo is read, or
when a redirect takes effect
(b) printing tool (and core) statistics at the end of a run
(c) after the run is finished, prints all the errors all over
again, to show the counts for each one
I propose the following changes:
(a) left unchanged
(b) tool-stats printing to be moved to a different flag,
-s | --tool-stats
(c) I find a major nuisance, because it prints so much output.
Perhaps it would be better to print, in each error, a unique
ID number (like in the XML format), and then, at the end,
print just one line per error, indicating the use count for each
error ID (much like how the used-suppressions info is printed).
Also, possibly use a different flag -c | --error-counts to
enable this output.
(4) There is a nonsensicality in how the error manager interacts
with tools, which has resulted in eg
https://bugs.kde.org/show_bug.cgi?id=186790
The symptom is that for Memcheck, the used suppressions list does
not list any suppressions used for suppressing leaks. This in
turn makes it difficult to debug and maintain suppressions files
for large projects. The reason is that the used-suppressions list
is printed before Memcheck is really finished, that is, after
the program has finished, but before Memcheck runs its leak check.
Proposed fix is to shut down the error manager only after we
call the tool's .fini function. Unfortunately this will
slightly change both the text and XML outputs for Memcheck.
J
|
|
From: Ashley P. <as...@pi...> - 2009-05-13 12:42:52
|
On Wed, 2009-05-13 at 13:16 +0200, Julian Seward wrote: > Hi, > > I've been mulling over some changes in how V emits output. It > seems to me the output systems are in need of an overhaul, to > fix various problems. > > (1) XML output on its own file descriptor. > > With --xml=yes, Memcheck can produce output in XML form, > which is useful for GUI writers, as it produces output in a > stable, easily parsed form. However, there have been various > complaints about the implementation. Specifically, XML > output goes on the same file descriptor as the "normal" > output. This has two bad effects: > The obvious fix is to have XML go on its own file descriptor, > so there are now two output channels which don't interfere. This would be a step forward and as you say make tools a lot more resilient. > --xml=yes still controls whether a tool does XML or text output > > --log-fd=, --log-file= and --log-socket= retain their existing > behaviour > > --xml=fd=, --xml-file= and --xml-socket= are added. These > specify the XML output channel. What would happen to normal output when xml is enabled? How should tools act if xml is enabled and output appears on the standard FD? > One advantage is that "normal" text-mode users will see no > difference. For GUI writers, the use of --log-file= will > need to change to --xml-file=, but that's no big deal. It's a problem for software in the field but probably an acceptable cost. Ashley Pittman. |
|
From: Julian S. <js...@ac...> - 2009-05-13 12:55:47
|
> > --xml=yes still controls whether a tool does XML or text output > > > > --log-fd=, --log-file= and --log-socket= retain their existing > > behaviour > > > > --xml=fd=, --xml-file= and --xml-socket= are added. These > > specify the XML output channel. > > What would happen to normal output when xml is enabled? How should > tools act if xml is enabled and output appears on the standard FD? Normal output just goes on the normal-output channel. For the most part, --xml=yes does not inhibit that any more. So the GUI could specify (eg) --xml=yes --xml-file=whatever.xml --log-file=/dev/null if it doesn't want to see the log output. Alternatively (and I forgot to mention this), perhaps it should be formalised, that -q quietens down the normal output so that only critical errors (eg, missing .supp file, etc) are printed. Which is pretty much what it does at present. In that case --xml=yes --xml-file=whatever.xml -q --log-file=criticalerrors.txt would result in criticalerrors.txt being empty if there are no critical errors, or being nonempty, in which case it would contain something that should be brought to the attention of the user. J |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-14 02:25:19
|
On Thu, May 14, 2009 at 11:31 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Wed, May 13, 2009 at 9:16 PM, Julian Seward <js...@ac...> wrote: >> >> I've been mulling over some changes in how V emits output. It >> seems to me the output systems are in need of an overhaul, to >> fix various problems. > > It all sounds good to me Actually, one very important question: when do you imagine this would be merged with the trunk relative to the Darwin merge? I'd prefer the Darwin merge to happen earlier because it's big and complex. In comparison, the messaging merge would be big but fairly simple(?) Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-14 02:35:19
|
On Wed, May 13, 2009 at 9:16 PM, Julian Seward <js...@ac...> wrote: > > I've been mulling over some changes in how V emits output. It > seems to me the output systems are in need of an overhaul, to > fix various problems. It all sounds good to me, with one nitpick: > (b) tool-stats printing to be moved to a different flag, > -s | --tool-stats --tool-stats is a bad name if it covers core stats as well. Just --stats=yes would be fine. N |
|
From: Julian S. <js...@ac...> - 2009-05-14 07:43:22
|
On Thursday 14 May 2009, Nicholas Nethercote wrote: > On Wed, May 13, 2009 at 9:16 PM, Julian Seward <js...@ac...> wrote: > > I've been mulling over some changes in how V emits output. It > > seems to me the output systems are in need of an overhaul, to > > fix various problems. > > It all sounds good to me, with one nitpick: > > (b) tool-stats printing to be moved to a different flag, > > -s | --tool-stats > > --tool-stats is a bad name if it covers core stats as well. Just > --stats=yes would be fine. Yup. J |
|
From: Julian S. <js...@ac...> - 2009-05-14 08:05:23
|
> Actually, one very important question: when do you imagine this would > be merged with the trunk relative to the Darwin merge? I'd prefer the > Darwin merge to happen earlier because it's big and complex. Probably after Darwin, on the basis that Darwin is much more complex and difficult to merge, and also that it is pretty close to being merged. Do you have a tentative timescale on which to do the Darwin merge? J |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-14 08:08:51
|
On Thu, May 14, 2009 at 6:08 PM, Julian Seward <js...@ac...> wrote: > >> Actually, one very important question: when do you imagine this would >> be merged with the trunk relative to the Darwin merge? I'd prefer the >> Darwin merge to happen earlier because it's big and complex. > > Probably after Darwin, on the basis that Darwin is much more complex > and difficult to merge, and also that it is pretty close to being merged. > > Do you have a tentative timescale on which to do the Darwin merge? If all goes well, maybe by the end of next week? N |