|
From: Ashley P. <as...@pi...> - 2009-08-15 12:23:26
|
On Sat, 2009-08-15 at 21:52 +1000, Nicholas Nethercote wrote:
> On Sat, Aug 15, 2009 at 7:42 PM, Ashley Pittman<as...@pi...> wrote:
> >
> > Did you have any thoughts on the other points I mentioned, either
> > getting both sets of output and ideally a way of getting a qualifier in
> > over the --{log,file}-socket options.
>
> I don't know much about the qualifier issue. As for both sets of
> output, it's conceptually nice but does it have a practical use? (I
> think it would invalidate Julian's use case of looking in the non-XML
> text output to look for critical errors.) Having said that, the
> message printing code currently is ugly, there's lots of ad hoc tests
> all over the place to decide whether to print each message as text or
> XML or both, it would be great to have a simpler and more consistent
> story for all that.
I work in HPC (High performance computing) where applications are
written in MPI and run in parallel. Ideally I'd like to start a
valgrind-listener type process, pass the socket id to multiple valgrind
instances simultaneously and then report errors as the sum of the
instances rather than on a per instance basis.
As you say this does make Julian's use case invalid which is unfortunate
as it's a very useful one, perhaps it would be possible to print the
pre-amble and qualifiers only if using --log-socket and then test for
further output as a sign of critical error?
> I very much like the idea of testing the XML by converting it back to
> text and comparing with the text output, but it would be too much to
> do it for every regtest, I think. Is there a simple GPL-licensed XML
> parser that could be the starting point for this, preferably in C or
> Perl? Presumably.
Yes, I've written one in perl. It was to solve the problem above, at
the time I used files with a qualifier and then after the job had
finished loaded all the xml files. I would then re-write the "standard"
valgrind output prefixing each error with a "qualifier prefix" which is
the standard way of specifying processes within HPC. You'd end up with
an extra line for each error, as shown below.
==27271== [0,2-15]
==27271== Use of uninitialised value of size 8
==27271== at 0x187FCEC6: (within /usr/lib/libGLcore.so.180.44)
==27271== by 0x41FF6BF: (within /usr/lib/libGL.so.180.44)
==27271== by 0x41FF6BF: (within /usr/lib/libGL.so.180.44)
It order to test the xml parser and subsequent output code you could run
the program with only one input file without a prefix and it would
simply convert the output as best it could, I even hooked this into the
test suite so the regtests did this automatically and then tested the
resultant output in the normal way, by and large this worked well with a
few specific cases where it didn't.
That was a couple of years ago now, it's written in perl, GPL but will
probably need updating. It uses XML::Simple which is easy to code but
unfortunately quite slow with large XML files, I did make a stab at
re-writing it to use XML::Parser but this was taking more time than I
had available at the time.
Ashley,
--
Ashley Pittman, Bath, UK.
Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk
|