On Tue, 2012-02-14 at 13:54 +0000, Rob wrote:
> > One thing that might be relevant is that errors already have a
> > 32 bit value that identifies them uniquely. "struct _Error :: unique"
> > You can see them in the XML output, eg
> >
> > ./vg-in-place --xml=yes --xml-fd=1 memcheck/tests/errs1
> >
> > I would prefer to use them, rather than add yet another kind of
> > error-counter mechanism. But the problem is now to show the user
There is in fact already a mechanism which counts the number of printed
errors, used a.o. to tell the user
"More than %d errors detected. Subsequent errors\n"
"will still be recorded, but in less "
"detail than before.\n"
The idea behind the current --vgdb-error was to use this counting
mechanism.
The manual for --vgdb-error=<number> says:
"Tools that report errors will wait for "number" errors to be reported
before freezing the program and waiting for you to connect with GDB.
It follows that a value of zero will cause the gdbserver to be started
before your program is executed. This is typically used to insert
GDB breakpoints before execution, and also works with tools that
do not report errors, such as Massif."
I have a preference for this "number" errors to be reported, but if
the above is still not convincing, fine for me to use the unique concept
instead.
> > what --vgdb-error value is required for each error. The simple
> > thing to do is to print a line
> >
> > Use --vgdb-error=<unique> to make the GDB server stop at this error
> >
> > Problem is I don't really want to add printing of such lines by
> > default. Is it possible that we can make printing of them conditional
> > on some other command line option that must be present in order to
> > use the gdbserver?
Difficult to find a mandatory command line option as --vgdb=yes is the
default.
So, a new option would be needed (e.g.
--print-unique-error-nr=no|yes print error nr for each error
or maybe
--print-vgdb-error=no|yes print error nr to use for --vgdb-error
> Yes, allowing the <unique/> numbers in place of a count would be good.
> It wouldn't necessarily have to print the full usage method above as this
> could be documented in the manual.
> How about appending the numbers at the end of each error line, either by
> default or with an option?
>
> ==14600== Syscall param write(buf) points to uninitialised byte(s) (uid=0x2f9)
To make the link with --vgdb-error, maybe
==14600== Syscall param write(buf) points to uninitialised byte(s)
(--vgdb-error=761)
(I would in any case not use hexadecimal for this, so as to match the way
integers
options are read)
Numbering the errors (either with n_errs_shown or with unique) will for
sure help.
However, with multi-threaded applications, the order and numbering of
errors might not be easily reproduced from one run to another.
At work, a user is doing a nasty trick to survive in such a case: he
writes a suppression file for all errors preceeding the one he is
interested in. Not very easy but can be made better
by having a new command line option:
--vgdb-error-list=<filename> invoke gdbserver for each error described in
filename
The big advantage of this schema is that it is not sensitive
to scheduling/numbering/...
With this, gdbserver would be invoked either when the error nr is >=
--vgdb-error
or when it matches an error described in --vgdb-error-list.
The --vgdb-error-list=<filename> will use the same format as a suppression file.
Philippe
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
