Parsing the output file

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Parsing the output file

Darren Burns
Message
Hi,
 
The "commentary" output is human-readable, but I'm thinking about automatically detecting and reporting memory errors in our test suite that runs every night.
 
Currently the output is something like:
 
==19346==
==19346== Conditional jump or move depends on uninitialised value(s)
 
But it's hard for a program to pick out these errors because they're just text amongst other text.  Is there (or could there be) an option to make these errors easier to parse out?  I couldn't find any.
 
For example
 
==19346==
==19346== [ERROR #12345] Conditional jump or move depends on uninitialised value(s)
 
or perhaps
 
==19346==
==19346== [BEGIN ERROR #12345]
==19346== Conditional jump or move depends on uninitialised value(s)
...
==19346== [END ERROR #12345]
 
(where 12345 is the unique numeric code that corresponds to the "Condition jump" error in this case).
 
Thanks,
DB
 
Reply | Threaded
Open this post in threaded view
|

Re: Parsing the output file

njn (Bugzilla)-2
On Fri, 20 May 2005, Darren Burns wrote:

> But it's hard for a program to pick out these errors because they're just
> text amongst other text.  Is there (or could there be) an option to make
> these errors easier to parse out?  I couldn't find any.

Julian just added a --xml=yes option to the 3.0 repository at
valgrind.org.  Note that it's just been added, and could well change in
the future.

Also, you could look at how the GUIs such as Alleyoop and Valgui parse the
output.

N


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

RE: Parsing the output file

Darren Burns
In reply to this post by Darren Burns
RE: [Valgrind-users] Parsing the output file

Thanks for the idea, Nicolas.  I checked a couple of the GUIs and in the two I checked, they seem to be simply hunting for the text of the error messages.  If the phrasing of the message were changed, then these tools would break, of course.  Also, they'll miss any new error conditions that get added.  That's another reason why a marker in the output stream, such as "ERROR", would be useful.

The --xml=yes feature sounds like it might make this easier.  It might make more sense to change the syntax to --log-format=xml, so that other formats could be added later.  The default for this would be something like --log-format=plain (the current output).  And in fact for a machine-readable output, --log-format=raw could produce ONLY error messages.

This is just speculation, and food for thought.

Thanks for the input.
DB

-----Original Message-----
From: Nicholas Nethercote
Sent: Saturday, May 21, 2005 3:30 PM
To: Darren Burns
Subject: Re: [Valgrind-users] Parsing the output file


On Fri, 20 May 2005, Darren Burns wrote:

> But it's hard for a program to pick out these errors because they're
> just text amongst other text.  Is there (or could there be) an option
> to make these errors easier to parse out?  I couldn't find any.

Julian just added a --xml=yes option to the 3.0 repository at
valgrind.org.  Note that it's just been added, and could well change in
the future.

Also, you could look at how the GUIs such as Alleyoop and Valgui parse the
output.

N

Reply | Threaded
Open this post in threaded view
|

Re: Parsing the output file

Jeffrey Stedfast
In reply to this post by Darren Burns
On Fri, 2005-05-20 at 19:44 -0700, Darren Burns wrote:

> Hi,
>  
> The "commentary" output is human-readable, but I'm thinking about
> automatically detecting and reporting memory errors in our test suite
> that runs every night.
>  
> Currently the output is something like:
>  
> ==19346==
> ==19346== Conditional jump or move depends on uninitialised value(s)
>  
> But it's hard for a program to pick out these errors because they're
> just text amongst other text.  Is there (or could there be) an option
> to make these errors easier to parse out?  I couldn't find any.
>  
> For example
>  
> ==19346==
> ==19346== [ERROR #12345] Conditional jump or move depends on
> uninitialised value(s)
>  
> or perhaps
>  
> ==19346==
> ==19346== [BEGIN ERROR #12345]
> ==19346== Conditional jump or move depends on uninitialised value(s)
> ...
> ==19346== [END ERROR #12345]

it already works very similarly to this now

==<pid>==SPACEThread: <thread id>
==<pid>==SPACE<error>
==<pid>==SPACE SPACE SPACE...<details>
==<pid>==SPACE SPACE SPACE...<details>
==<pid>==

note that "blank" lines will end a report and that the error details are
indented farther than the error (not that it even needs to be in order
to be parseable since we know the first line is the error anyway)

I'll agree that a more machine parseable format would be nice, but it's
not really necessary to do what you want.

Jeff



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users