You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(13) |
2
(15) |
|
3
(16) |
4
(42) |
5
(9) |
6
(20) |
7
(22) |
8
(24) |
9
(12) |
|
10
(24) |
11
(11) |
12
(2) |
13
(13) |
14
(8) |
15
|
16
(16) |
|
17
(24) |
18
(36) |
19
(100) |
20
(94) |
21
(50) |
22
(39) |
23
(10) |
|
24
(14) |
25
(19) |
26
(2) |
27
(6) |
28
(17) |
29
(9) |
30
(8) |
|
31
(21) |
|
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2009-05-13 13:08:09
|
On Wednesday 13 May 2009, Josef Weidendorfer wrote: > On Wednesday 13 May 2009, 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. > > ... > > As far as I see, this has nothing to do with the output of tools > such as cachegrind/callgrind, which always dumped data to a file > in its own format... ? Yes. Cachegrind/Callgrind/Massif are unaffected. J |
|
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: 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 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: Julian S. <js...@ac...> - 2009-05-13 11:09:29
|
On Friday 08 May 2009, Philippe Waroquiers wrote: > Another alternative would be to use the word differentiation > (because the printed stacks will be precise but not differentiated) > i.e. > --leak-resolution=low|med|high differentiation of stack traces in > leak check [high] Yes, I think that's the best proposal so far. I'd go with that. J |
|
From: <sv...@va...> - 2009-05-13 08:36:07
|
Author: sewardj
Date: 2009-05-13 09:35:54 +0100 (Wed, 13 May 2009)
New Revision: 9843
Log:
First try at XML output for Helgrind, using Protocol 4.
Also removes the un-used FreeMemLock error kind.
Modified:
branches/MESSAGING_TIDYUP/helgrind/hg_errors.c
branches/MESSAGING_TIDYUP/helgrind/hg_errors.h
branches/MESSAGING_TIDYUP/helgrind/hg_main.c
Modified: branches/MESSAGING_TIDYUP/helgrind/hg_errors.c
===================================================================
--- branches/MESSAGING_TIDYUP/helgrind/hg_errors.c 2009-05-13 08:34:15 UTC (rev 9842)
+++ branches/MESSAGING_TIDYUP/helgrind/hg_errors.c 2009-05-13 08:35:54 UTC (rev 9843)
@@ -39,6 +39,7 @@
#include "pub_tool_xarray.h"
#include "pub_tool_debuginfo.h"
#include "pub_tool_threadstate.h"
+#include "pub_tool_options.h" // VG_(clo_xml)
#include "hg_basics.h"
#include "hg_wordset.h"
@@ -48,19 +49,9 @@
/*----------------------------------------------------------------*/
-/*--- ---*/
+/*--- Error management -- storage ---*/
/*----------------------------------------------------------------*/
-/* This has to do with printing error messages. See comments on
- announce_threadset() and summarise_threadset(). Perhaps it
- should be a command line option. */
-#define N_THREADS_TO_ANNOUNCE 5
-
-
-/*----------------------------------------------------------------*/
-/*--- Error management ---*/
-/*----------------------------------------------------------------*/
-
/* maps (by value) strings to a copy of them in ARENA_TOOL */
static WordFM* string_table = NULL;
@@ -168,7 +159,6 @@
typedef
enum {
XE_Race=1101, // race
- XE_FreeMemLock, // freeing memory containing a locked lock
XE_UnlockUnlocked, // unlocking a not-locked lock
XE_UnlockForeign, // unlocking a lock held by some other thread
XE_UnlockBogus, // unlocking an address not known to be a lock
@@ -197,10 +187,6 @@
Char descr2[96];
} Race;
struct {
- Thread* thr; /* doing the freeing */
- Lock* lock; /* lock which is locked */
- } FreeMemLock;
- struct {
Thread* thr; /* doing the unlocking */
Lock* lock; /* lock (that is already unlocked) */
} UnlockUnlocked;
@@ -364,22 +350,6 @@
XE_Race, data_addr, NULL, &xe );
}
-void HG_(record_error_FreeMemLock) ( Thread* thr, Lock* lk )
-{
- XError xe;
- tl_assert( HG_(is_sane_Thread)(thr) );
- tl_assert( HG_(is_sane_LockN)(lk) );
- init_XError(&xe);
- xe.tag = XE_FreeMemLock;
- xe.XE.FreeMemLock.thr = thr;
- xe.XE.FreeMemLock.lock = mk_LockP_from_LockN(lk);
- // FIXME: tid vs thr
- tl_assert( HG_(is_sane_ThreadId)(thr->coretid) );
- tl_assert( thr->coretid != VG_INVALID_THREADID );
- VG_(maybe_record_error)( thr->coretid,
- XE_FreeMemLock, 0, NULL, &xe );
-}
-
void HG_(record_error_UnlockUnlocked) ( Thread* thr, Lock* lk )
{
XError xe;
@@ -507,9 +477,6 @@
&& (HG_(clo_cmp_race_err_addrs)
? xe1->XE.Race.data_addr == xe2->XE.Race.data_addr
: True);
- case XE_FreeMemLock:
- return xe1->XE.FreeMemLock.thr == xe2->XE.FreeMemLock.thr
- && xe1->XE.FreeMemLock.lock == xe2->XE.FreeMemLock.lock;
case XE_UnlockUnlocked:
return xe1->XE.UnlockUnlocked.thr == xe2->XE.UnlockUnlocked.thr
&& xe1->XE.UnlockUnlocked.lock == xe2->XE.UnlockUnlocked.lock;
@@ -539,13 +506,49 @@
}
+/*----------------------------------------------------------------*/
+/*--- Error management -- printing ---*/
+/*----------------------------------------------------------------*/
+
+/* Do a printf-style operation on either the XML or normal output
+ channel, depending on the setting of VG_(clo_xml).
+*/
+static void emit_WRK ( HChar* format, va_list vargs )
+{
+ if (VG_(clo_xml)) {
+ VG_(vprintf_xml)(format, vargs);
+ } else {
+ VG_(vmessage)(Vg_UserMsg, format, vargs);
+ }
+}
+static void emit ( HChar* format, ... ) PRINTF_CHECK(1, 2);
+static void emit ( HChar* format, ... )
+{
+ va_list vargs;
+ va_start(vargs, format);
+ emit_WRK(format, vargs);
+ va_end(vargs);
+}
+static void emit_no_f_c ( HChar* format, ... )
+{
+ va_list vargs;
+ va_start(vargs, format);
+ emit_WRK(format, vargs);
+ va_end(vargs);
+}
+
+
/* Announce (that is, print the point-of-creation) of 'thr'. Only do
this once, as we only want to see these announcements once per
- thread. */
+ thread. For the moment, don't do this in XML mode, as there is no
+ provision for representing the result in XML Protocol 4 output.
+*/
static void announce_one_thread ( Thread* thr )
{
tl_assert(HG_(is_sane_Thread)(thr));
tl_assert(thr->errmsg_index >= 1);
+ if (VG_(clo_xml))
+ return;
if (!thr->announced) {
if (thr->errmsg_index == 1) {
tl_assert(thr->created_at == NULL);
@@ -565,6 +568,13 @@
void HG_(pp_Error) ( Error* err )
{
+ HChar* what_pre0 = VG_(clo_xml) ? " <what>" : "";
+ HChar* what_pre3 = VG_(clo_xml) ? " <what>" : " ";
+ HChar* what_post = VG_(clo_xml) ? "</what>" : "";
+ HChar* auxw_pre1 = VG_(clo_xml) ? " <auxwhat>" : " ";
+ HChar* auxw_pre2 = VG_(clo_xml) ? " <auxwhat>" : " ";
+ HChar* auxw_post = VG_(clo_xml) ? "</auxwhat>" : "";
+
XError *xe = (XError*)VG_(get_error_extra)(err);
switch (VG_(get_error_kind)(err)) {
@@ -573,10 +583,13 @@
tl_assert(xe);
tl_assert( HG_(is_sane_Thread)( xe->XE.Misc.thr ) );
announce_one_thread( xe->XE.Misc.thr );
- VG_(message)(Vg_UserMsg,
- "Thread #%d: %s\n",
- (Int)xe->XE.Misc.thr->errmsg_index,
- xe->XE.Misc.errstr);
+ if (VG_(clo_xml))
+ VG_(printf_xml)( " <kind>Misc</kind>\n");
+ emit( "%sThread #%d: %s%s\n",
+ what_pre0,
+ (Int)xe->XE.Misc.thr->errmsg_index,
+ xe->XE.Misc.errstr,
+ what_post );
VG_(pp_ExeContext)( VG_(get_error_where)(err) );
break;
}
@@ -585,20 +598,25 @@
tl_assert(xe);
tl_assert( HG_(is_sane_Thread)( xe->XE.LockOrder.thr ) );
announce_one_thread( xe->XE.LockOrder.thr );
- VG_(message)(Vg_UserMsg,
- "Thread #%d: lock order \"%p before %p\" violated\n",
- (Int)xe->XE.LockOrder.thr->errmsg_index,
- (void*)xe->XE.LockOrder.before_ga,
- (void*)xe->XE.LockOrder.after_ga);
+ if (VG_(clo_xml))
+ VG_(printf_xml)( " <kind>LockOrder</kind>\n");
+ emit( "%sThread #%d: lock order \"%p before %p\" violated%s\n",
+ what_pre0,
+ (Int)xe->XE.LockOrder.thr->errmsg_index,
+ (void*)xe->XE.LockOrder.before_ga,
+ (void*)xe->XE.LockOrder.after_ga,
+ what_post );
VG_(pp_ExeContext)( VG_(get_error_where)(err) );
if (xe->XE.LockOrder.before_ec && xe->XE.LockOrder.after_ec) {
- VG_(message)(Vg_UserMsg,
- " Required order was established by acquisition of lock at %p\n",
- (void*)xe->XE.LockOrder.before_ga);
+ emit(
+ "%sRequired order was established by acquisition of lock at %p%s\n",
+ auxw_pre2, (void*)xe->XE.LockOrder.before_ga, auxw_post
+ );
VG_(pp_ExeContext)( xe->XE.LockOrder.before_ec );
- VG_(message)(Vg_UserMsg,
- " followed by a later acquisition of lock at %p\n",
- (void*)xe->XE.LockOrder.after_ga);
+ emit(
+ "%sfollowed by a later acquisition of lock at %p%s\n",
+ auxw_pre2, (void*)xe->XE.LockOrder.after_ga, auxw_post
+ );
VG_(pp_ExeContext)( xe->XE.LockOrder.after_ec );
}
break;
@@ -608,14 +626,15 @@
tl_assert(xe);
tl_assert( HG_(is_sane_Thread)( xe->XE.PthAPIerror.thr ) );
announce_one_thread( xe->XE.PthAPIerror.thr );
- VG_(message)(Vg_UserMsg,
- "Thread #%d's call to %s failed\n",
- (Int)xe->XE.PthAPIerror.thr->errmsg_index,
- xe->XE.PthAPIerror.fnname);
- VG_(message)(Vg_UserMsg,
- " with error code %ld (%s)\n",
- xe->XE.PthAPIerror.err,
- xe->XE.PthAPIerror.errstr);
+ if (VG_(clo_xml))
+ VG_(printf_xml)( " <kind>PthAPIerror</kind>\n");
+ emit_no_f_c( "%sThread #%d's call to %t failed%s\n",
+ what_pre0, (Int)xe->XE.PthAPIerror.thr->errmsg_index,
+ xe->XE.PthAPIerror.fnname, what_post );
+ emit( "%swith error code %ld (%s)%s\n",
+ what_pre3,
+ xe->XE.PthAPIerror.err, xe->XE.PthAPIerror.errstr,
+ what_post );
VG_(pp_ExeContext)( VG_(get_error_where)(err) );
break;
}
@@ -624,10 +643,13 @@
tl_assert(xe);
tl_assert( HG_(is_sane_Thread)( xe->XE.UnlockBogus.thr ) );
announce_one_thread( xe->XE.UnlockBogus.thr );
- VG_(message)(Vg_UserMsg,
- "Thread #%d unlocked an invalid lock at %p \n",
- (Int)xe->XE.UnlockBogus.thr->errmsg_index,
- (void*)xe->XE.UnlockBogus.lock_ga);
+ if (VG_(clo_xml))
+ VG_(printf_xml)( " <kind>UnlockBogus</kind>\n");
+ emit( "%sThread #%d unlocked an invalid lock at %p %s\n",
+ what_pre0,
+ (Int)xe->XE.UnlockBogus.thr->errmsg_index,
+ (void*)xe->XE.UnlockBogus.lock_ga,
+ what_post );
VG_(pp_ExeContext)( VG_(get_error_where)(err) );
break;
}
@@ -639,17 +661,21 @@
tl_assert( HG_(is_sane_Thread)( xe->XE.UnlockForeign.thr ) );
announce_one_thread( xe->XE.UnlockForeign.thr );
announce_one_thread( xe->XE.UnlockForeign.owner );
- VG_(message)(Vg_UserMsg,
- "Thread #%d unlocked lock at %p "
- "currently held by thread #%d\n",
- (Int)xe->XE.UnlockForeign.thr->errmsg_index,
- (void*)xe->XE.UnlockForeign.lock->guestaddr,
- (Int)xe->XE.UnlockForeign.owner->errmsg_index );
+ if (VG_(clo_xml))
+ VG_(printf_xml)( " <kind>UnlockForeign</kind>\n");
+ emit( "%sThread #%d unlocked lock at %p "
+ "currently held by thread #%d%s\n",
+ what_pre0,
+ (Int)xe->XE.UnlockForeign.thr->errmsg_index,
+ (void*)xe->XE.UnlockForeign.lock->guestaddr,
+ (Int)xe->XE.UnlockForeign.owner->errmsg_index,
+ what_post );
VG_(pp_ExeContext)( VG_(get_error_where)(err) );
if (xe->XE.UnlockForeign.lock->appeared_at) {
- VG_(message)(Vg_UserMsg,
- " Lock at %p was first observed\n",
- (void*)xe->XE.UnlockForeign.lock->guestaddr);
+ emit( "%sLock at %p was first observed%s\n",
+ auxw_pre2,
+ (void*)xe->XE.UnlockForeign.lock->guestaddr,
+ auxw_post );
VG_(pp_ExeContext)( xe->XE.UnlockForeign.lock->appeared_at );
}
break;
@@ -660,40 +686,24 @@
tl_assert( HG_(is_sane_LockP)( xe->XE.UnlockUnlocked.lock ) );
tl_assert( HG_(is_sane_Thread)( xe->XE.UnlockUnlocked.thr ) );
announce_one_thread( xe->XE.UnlockUnlocked.thr );
- VG_(message)(Vg_UserMsg,
- "Thread #%d unlocked a not-locked lock at %p \n",
- (Int)xe->XE.UnlockUnlocked.thr->errmsg_index,
- (void*)xe->XE.UnlockUnlocked.lock->guestaddr);
+ if (VG_(clo_xml))
+ VG_(printf_xml)( " <kind>UnlockUnlocked</kind>\n");
+ emit( "%sThread #%d unlocked a not-locked lock at %p %s\n",
+ what_pre0,
+ (Int)xe->XE.UnlockUnlocked.thr->errmsg_index,
+ (void*)xe->XE.UnlockUnlocked.lock->guestaddr,
+ what_post );
VG_(pp_ExeContext)( VG_(get_error_where)(err) );
if (xe->XE.UnlockUnlocked.lock->appeared_at) {
- VG_(message)(Vg_UserMsg,
- " Lock at %p was first observed\n",
- (void*)xe->XE.UnlockUnlocked.lock->guestaddr);
+ emit( "%sLock at %p was first observed%s\n",
+ auxw_pre2,
+ (void*)xe->XE.UnlockUnlocked.lock->guestaddr,
+ auxw_post );
VG_(pp_ExeContext)( xe->XE.UnlockUnlocked.lock->appeared_at );
}
break;
}
- case XE_FreeMemLock: {
- tl_assert(xe);
- tl_assert( HG_(is_sane_LockP)( xe->XE.FreeMemLock.lock ) );
- tl_assert( HG_(is_sane_Thread)( xe->XE.FreeMemLock.thr ) );
- announce_one_thread( xe->XE.FreeMemLock.thr );
- VG_(message)(Vg_UserMsg,
- "Thread #%d deallocated location %p "
- "containing a locked lock\n",
- (Int)xe->XE.FreeMemLock.thr->errmsg_index,
- (void*)xe->XE.FreeMemLock.lock->guestaddr);
- VG_(pp_ExeContext)( VG_(get_error_where)(err) );
- if (xe->XE.FreeMemLock.lock->appeared_at) {
- VG_(message)(Vg_UserMsg,
- " Lock at %p was first observed\n",
- (void*)xe->XE.FreeMemLock.lock->guestaddr);
- VG_(pp_ExeContext)( xe->XE.FreeMemLock.lock->appeared_at );
- }
- break;
- }
-
case XE_Race: {
Addr err_ga;
HChar* what;
@@ -705,36 +715,46 @@
announce_one_thread( xe->XE.Race.thr );
if (xe->XE.Race.mb_confaccthr)
announce_one_thread( xe->XE.Race.mb_confaccthr );
- VG_(message)(Vg_UserMsg,
- "Possible data race during %s of size %d at %#lx by thread #%d\n",
- what, szB, err_ga, (Int)xe->XE.Race.thr->errmsg_index
+ if (VG_(clo_xml))
+ VG_(printf_xml)( " <kind>Race</kind>\n");
+ emit(
+ "%sPossible data race during %s of size %d "
+ "at %#lx by thread #%d%s\n",
+ what_pre0, what, szB, err_ga,
+ (Int)xe->XE.Race.thr->errmsg_index, what_post
);
VG_(pp_ExeContext)( VG_(get_error_where)(err) );
if (xe->XE.Race.mb_confacc) {
if (xe->XE.Race.mb_confaccthr) {
- VG_(message)(Vg_UserMsg,
- " This conflicts with a previous %s of size %d by thread #%d\n",
+ emit(
+ "%sThis conflicts with a previous %s of size %d "
+ "by thread #%d%s\n",
+ auxw_pre1,
xe->XE.Race.mb_confaccIsW ? "write" : "read",
xe->XE.Race.mb_confaccSzB,
- xe->XE.Race.mb_confaccthr->errmsg_index
+ xe->XE.Race.mb_confaccthr->errmsg_index,
+ auxw_post
);
} else {
// FIXME: can this ever happen?
- VG_(message)(Vg_UserMsg,
- " This conflicts with a previous %s of size %d\n",
+ emit(
+ "%sThis conflicts with a previous %s of size %d%s\n",
+ auxw_pre1,
xe->XE.Race.mb_confaccIsW ? "write" : "read",
- xe->XE.Race.mb_confaccSzB
+ xe->XE.Race.mb_confaccSzB,
+ auxw_post
);
}
VG_(pp_ExeContext)( xe->XE.Race.mb_confacc );
}
-
/* If we have a better description of the address, show it. */
if (xe->XE.Race.descr1[0] != 0)
- VG_(message)(Vg_UserMsg, " %s\n", &xe->XE.Race.descr1[0]);
+ emit_no_f_c( "%s%t%s\n",
+ auxw_pre1, &xe->XE.Race.descr1[0], auxw_post );
if (xe->XE.Race.descr2[0] != 0)
- VG_(message)(Vg_UserMsg, " %s\n", &xe->XE.Race.descr2[0]);
+ emit_no_f_c( "%s%t%s\n",
+ auxw_pre1, &xe->XE.Race.descr2[0], auxw_post );
break; /* case XE_Race */
} /* case XE_Race */
@@ -748,7 +768,6 @@
{
switch (VG_(get_error_kind)(err)) {
case XE_Race: return "Race";
- case XE_FreeMemLock: return "FreeMemLock";
case XE_UnlockUnlocked: return "UnlockUnlocked";
case XE_UnlockForeign: return "UnlockForeign";
case XE_UnlockBogus: return "UnlockBogus";
@@ -790,7 +809,6 @@
{
switch (VG_(get_supp_kind)(su)) {
case XS_Race: return VG_(get_error_kind)(err) == XE_Race;
- case XS_FreeMemLock: return VG_(get_error_kind)(err) == XE_FreeMemLock;
case XS_UnlockUnlocked: return VG_(get_error_kind)(err) == XE_UnlockUnlocked;
case XS_UnlockForeign: return VG_(get_error_kind)(err) == XE_UnlockForeign;
case XS_UnlockBogus: return VG_(get_error_kind)(err) == XE_UnlockBogus;
Modified: branches/MESSAGING_TIDYUP/helgrind/hg_errors.h
===================================================================
--- branches/MESSAGING_TIDYUP/helgrind/hg_errors.h 2009-05-13 08:34:15 UTC (rev 9842)
+++ branches/MESSAGING_TIDYUP/helgrind/hg_errors.h 2009-05-13 08:35:54 UTC (rev 9843)
@@ -49,7 +49,6 @@
void HG_(record_error_Race) ( Thread* thr,
Addr data_addr, Int szB, Bool isWrite,
ExeContext* mb_lastlock );
-void HG_(record_error_FreeMemLock) ( Thread* thr, Lock* lk );
void HG_(record_error_UnlockUnlocked) ( Thread*, Lock* );
void HG_(record_error_UnlockForeign) ( Thread*, Thread*, Lock* );
void HG_(record_error_UnlockBogus) ( Thread*, Addr );
Modified: branches/MESSAGING_TIDYUP/helgrind/hg_main.c
===================================================================
--- branches/MESSAGING_TIDYUP/helgrind/hg_main.c 2009-05-13 08:34:15 UTC (rev 9842)
+++ branches/MESSAGING_TIDYUP/helgrind/hg_main.c 2009-05-13 08:35:54 UTC (rev 9843)
@@ -4204,6 +4204,8 @@
HG_(get_error_name),
HG_(print_extra_suppression_info));
+ VG_(needs_xml_output) ();
+
VG_(needs_command_line_options)(hg_process_cmd_line_option,
hg_print_usage,
hg_print_debug_usage);
|
|
From: <sv...@va...> - 2009-05-13 08:34:27
|
Author: sewardj
Date: 2009-05-13 09:34:15 +0100 (Wed, 13 May 2009)
New Revision: 9842
Log:
Create a 4th version of the XML output format specification ("Protocol 4")
for use with the 3.5.x branch.
Added:
branches/MESSAGING_TIDYUP/docs/internals/xml-output-protocol4.txt
Modified:
branches/MESSAGING_TIDYUP/docs/internals/Makefile.am
branches/MESSAGING_TIDYUP/docs/internals/xml-output.txt
Modified: branches/MESSAGING_TIDYUP/docs/internals/Makefile.am
===================================================================
--- branches/MESSAGING_TIDYUP/docs/internals/Makefile.am 2009-05-13 08:25:56 UTC (rev 9841)
+++ branches/MESSAGING_TIDYUP/docs/internals/Makefile.am 2009-05-13 08:34:15 UTC (rev 9842)
@@ -15,4 +15,5 @@
segments-seginfos.txt threads-syscalls-signals.txt \
tm-mutexstates.dot tm-threadstates.dot tracking-fn-entry-exit.txt \
why-no-libc.txt \
- xml-output.txt
+ xml-output.txt \
+ xml-output-protocol4.txt
Added: branches/MESSAGING_TIDYUP/docs/internals/xml-output-protocol4.txt
===================================================================
--- branches/MESSAGING_TIDYUP/docs/internals/xml-output-protocol4.txt (rev 0)
+++ branches/MESSAGING_TIDYUP/docs/internals/xml-output-protocol4.txt 2009-05-13 08:34:15 UTC (rev 9842)
@@ -0,0 +1,595 @@
+
+====================================================================
+
+11 May 2009
+
+Protocols 1 through 3 supported Memcheck only. Protocol 4 provides
+XML output for Memcheck, Helgrind and Ptrcheck. Technically there are
+three variants of Protocol 4, one for each tool, since they produce
+different errors. The three variants differ only in the definition of
+the ERROR nonterminal and are otherwise identical.
+
+NOTE that Protocol 4 (for the current svn trunk, which will eventually
+become 3.5.x) is still under development. The text herein should not
+be regarded as the final definition.
+
+
+Identification of Protocols
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In Protocols 1 through 3, a <protocolversion>INT<protocolversion>
+close to the start of the stream makes it possible for parsers to
+ascertain the version, so they can tell whether or not they can handle
+it. The presence of support for multiple tools brings a complication,
+though: it is not enough merely to state the protocol version -- the
+tool name must also be stated. Hence in Protocol 4, the
+<protocolversion>INT<protocolversion> is followed immediately by
+<protocoltool>TEXT</protocoltool>, to identify the tool.
+
+This duplicates the tool name present later in the preamble, but it
+was felt important to place the tool name right at the front along
+with the protocol number, for easy determination of parseability.
+
+
+Protocol 4 changes for Memcheck
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Protocol 4 for Memcheck is identical to Protocol 3, except that
+
+- the SUPPCOUNTS nonterminal now appears after the "Zero or more
+ ERRORs" block, and not before it.
+
+- the abovementioned "Zero or more ERRORs" block now becomes
+ "Zero or more of (either ERROR or ERRORCOUNTS)".
+
+- ERRORs for Memcheck may contain a SUPPRESSION field, which gives
+ the corresponding suppression for it.
+
+The first two changes are required in order to correct a longstanding
+design flaw in the way Memcheck interacts with Valgrind's error
+management mechanism. See bug #186790
+(https://bugs.kde.org/show_bug.cgi?id=186790). The third change was
+requested in #191189 (https://bugs.kde.org/show_bug.cgi?id=191189).
+
+The definition of Protocol 4 now follows. It is structured similarly
+to that of the previous protocols, except that there is a separate
+definition of ERROR for each of Memcheck, Helgrind and Ptrcheck.
+
+
+====================================================================
+
+TOPLEVEL
+--------
+
+The first line output is always this:
+
+ <?xml version="1.0"?>
+
+All remaining output is contained within the tag-pair
+<valgrindoutput>.
+
+Inside that, the first entity is an indication of the protocol
+version. This is provided so that existing parsers can identify XML
+created by future versions of Valgrind merely by observing that the
+protocol version is one they don't understand. Hence TOPLEVEL is:
+
+ <?xml version="1.0"?>
+ <valgrindoutput>
+ <protocolversion>INT<protocolversion>
+ <protocoltool>TEXT</protocoltool>
+ PROTOCOL
+ </valgrindoutput>
+
+Valgrind versions 3.0.0 and 3.0.1 emit protocol version 1. Versions
+3.1.X and 3.2.X [and 3.3.X ??] emit protocol version 2. 3.4.X emits
+protocol version 3. 3.5.X emits version 4.
+
+The TEXT in <protocoltool> is either "memcheck", "helgrind" or
+"ptrcheck" and determines the allowed format of the ERROR nonterminal.
+Note that <protocoltool> is only present when the protocol version is
+4 or above.
+
+
+PROTOCOL for version 4
+----------------------
+
+This is the main top-level construction. Roughly speaking, it
+contains a preamble, a program-started marker, the errors from the run
+of the program, a program-ended marker, and any further errors
+resulting from post-run analysis (eg, memory leak detection). Hence
+the following in sequence:
+
+* Various preamble lines which give version info for the various
+ components. The text in them can be anything; it is not intended
+ for interpretation by the GUI:
+
+ <preamble>
+ <line>Misc version/copyright text</line> (zero or more of)
+ </preamble>
+
+* The PID of this process and of its parent:
+
+ <pid>INT</pid>
+ <ppid>INT</ppid>
+
+* The name of the tool being used:
+
+ <tool>TEXT</tool>
+
+ This can be anything, and it doesn't have to match the
+ <protocoltool> entry, although that might be wise.
+
+* Zero or more bindings of environment variable names to actual
+ values. These describe precisely the instantiations of %q format
+ specifiers used in the --xml-file= argument for the run, if any.
+ There is one <logfilequalifier> entry for each %q expanded:
+
+ <logfilequalifier> <var>VAR</var> <value>$VAR</value>
+ </logfilequalifier>
+
+* OPTIONALLY, if --xml-user-comment=STRING was given:
+
+ <usercomment>STRING</usercomment>
+
+ STRING is not escaped in any way, so that it itself may be a piece
+ of XML with arbitrary tags etc.
+
+* The program and args: first those pertaining to Valgrind itself, and
+ then those pertaining to the program to be run under Valgrind (the
+ client):
+
+ <args>
+ <vargv>
+ <exe>TEXT</exe>
+ <arg>TEXT</arg> (zero or more of)
+ </vargv>
+ <argv>
+ <exe>TEXT</exe>
+ <arg>TEXT</arg> (zero or more of)
+ </argv>
+ </args>
+
+* The following, indicating that the program has now started:
+
+ <status> <state>RUNNING</state>
+ <time>human-readable-time-string</time>
+ </status>
+
+ The format of this string is not defined, but it is expected to be
+ human-understandable. In current Valgrind versions it is the
+ elapsed wallclock time since process start.
+
+* Zero or more of (either ERROR or ERRORCOUNTS).
+
+* The following, indicating that the program has now finished, and
+ that the any final wrapup (eg, for Memcheck, leak checking) is happening.
+
+ <status> <state>FINISHED</state>
+ <time>human-readable-time-string</time>
+ </status>
+
+* Zero or more of (either ERROR or ERRORCOUNTS). In Memcheck's case
+ these will be complaints from the leak checker. For Ptrcheck and
+ Helgrind we don't expect any output here (but the spec does not
+ guarantee that either).
+
+* SUPPCOUNTS, indicating how many times each suppression was used.
+
+
+That's it. The tool-specific definitions for ERROR are below; however
+let's first continue with some smaller nonterminals used in the
+construction of errors for all the tool types.
+
+
+====================================================================
+
+Nonterminals used in construction of ERRORs
+-------------------------------------------
+
+STACK
+-----
+STACK indicates locations in the program being debugged. A STACK
+is one or more FRAMEs. The first is the innermost frame, the
+next its caller, etc.
+
+ <stack>
+ one or more FRAME
+ </stack>
+
+
+FRAME
+-----
+FRAME records a single program location:
+
+ <frame>
+ <ip>HEX64</ip>
+ optionally <obj>TEXT</obj>
+ optionally <fn>TEXT</fn>
+ optionally <dir>TEXT</dir>
+ optionally <file>TEXT</file>
+ optionally <line>INT</line>
+ </frame>
+
+Only the <ip> field is guaranteed to be present. It indicates a
+code ("instruction pointer") address.
+
+The optional fields, if present, appear in the order stated:
+
+* obj: gives the name of the ELF object containing the code address
+
+* fn: gives the name of the function containing the code address
+
+* dir: gives the source directory associated with the name specified
+ by <file>. Note the current implementation often does not
+ put anything useful in this field.
+
+* file: gives the name of the source file containing the code address
+
+* line: gives the line number in the source file
+
+
+ERRORCOUNTS
+-----------
+This specifies, for each error that has been so far presented,
+the number of occurrences of that error.
+
+ <errorcounts>
+ zero or more of
+ <pair> <count>INT</count> <unique>HEX64</unique> </pair>
+ </errorcounts>
+
+Each <pair> gives the current error count <count> for the error with
+unique tag </unique>. The counts do not have to give a count for each
+error so far presented - partial information is allowable.
+
+As at Valgrind rev 3793, error counts are only emitted at program
+termination. However, it is perfectly acceptable to periodically emit
+error counts as the program is running. Doing so would facilitate a
+GUI to dynamically update its error-count display as the program runs.
+
+
+SUPPCOUNTS
+----------
+A SUPPCOUNTS block appears exactly once, after the program terminates.
+It specifies the number of times each error-suppression was used.
+Suppressions not mentioned were used zero times.
+
+ <suppcounts>
+ zero or more of
+ <pair> <count>INT</count> <name>TEXT</name> </pair>
+ </suppcounts>
+
+The <name> is as specified in the suppression name fields in .supp
+files.
+
+
+SUPPRESSION
+-----------
+These are optionally emitted as part of ERRORs, and specify the
+suppression that would be needed to suppress the containing error.
+
+ <suppression>
+ <sname>TEXT</sname> name of the suppression
+ <skind>TEXT</skind> kind, eg "Memcheck:Param"
+ <skaux>TEXT</skaux> (optional) aux kind, eg "write(buf)"
+ SFRAME (one or more) frames
+ </suppression>
+
+
+SFRAME
+------
+Either
+
+ <sframe> <obj>TEXT</obj> </sframe>
+
+eg denoting "obj:/usr/X11R6/lib*/libX11.so.6.2", or
+
+ <sframe> <fun>TEXT</fun> </sframe>
+
+eg denoting "fun:*libc_write"
+
+
+====================================================================
+
+ERROR definition -- common fields
+---------------------------------
+
+ERROR defines an error, and is the most complex nonterminal. For all
+of the tools, the first four fields and the last field are common:
+
+ <error>
+ <unique>HEX64</unique>
+ <tid>INT</tid>
+ <kind>KIND</kind>
+ <what>TEXT</what> (either 1 or 2 times)
+
+ ... tool-specific fields ...
+
+ optionally: SUPPRESSION
+ </error>
+
+
+* Each error contains a unique, arbitrary 64-bit hex number. This is
+ used to refer to the error in ERRORCOUNTS nonterminals (see below).
+
+* The <tid> tag indicates the Valgrind thread number. This value
+ is arbitrary but may be used to determine which threads produced
+ which errors (at least, the first instance of each error).
+
+* The <kind> tag specifies one of a small number of fixed error types,
+ so that GUIs may roughly categorise errors by type if they want.
+ The tags themselves are tool-specific and are defined further
+ below, for each tool.
+
+* The <what> tag gives a human-understandable description of the
+ error. There may be two consecutive <what>TEXT</what> blocks, in
+ which case the second block gives further details, and should be
+ displayed by GUIs immediately following the first one.
+
+* Finally, optionally, a SUPPRESSION may be provided. This contains
+ a suppression that would hide the error.
+
+
+====================================================================
+
+ERROR definition for Memcheck
+-----------------------------
+
+The definition is:
+
+ <error>
+ <unique>HEX64</unique>
+ <tid>INT</tid>
+ <kind>KIND</kind>
+ <what>TEXT</what> (either 1 or 2 times)
+
+ optionally: <leakedbytes>INT</leakedbytes>
+ optionally: <leakedblocks>INT</leakedblocks>
+
+ STACK
+
+ zero, one or two: <auxwhat>TEXT</auxwhat>
+ optionally: STACK
+ optionally: ORIGIN
+
+ optionally: SUPPRESSION
+ </error>
+
+
+The first four fields and the last field are specified in "ERROR
+definition -- common fields" above. The remaining fields are as
+follows:
+
+* For <kind> tags specifying a KIND of the form "Leak_*", the
+ optional <leakedbytes> and <leakedblocks> indicate the number of
+ bytes and blocks leaked by this error.
+
+* The primary STACK for this error, indicating where it occurred.
+
+* Some error types may have auxiliary information attached:
+
+ <auxwhat>TEXT</auxwhat> (zero, one or two) gives an auxiliary
+ human-readable description (usually of invalid addresses)
+
+ STACK gives an auxiliary stack (usually the allocation/free point
+ of a block). If this STACK is present then the
+ <auxwhat>TEXT</auxwhat> blocks will precede it.
+
+
+KIND for Memcheck
+-----------------
+
+This is a small enumeration indicating roughly the nature of an error.
+The possible values are:
+
+ InvalidFree
+
+ free/delete/delete[] on an invalid pointer
+
+ MismatchedFree
+
+ free/delete/delete[] does not match allocation function
+ (eg doing new[] then free on the result)
+
+ InvalidRead
+
+ read of an invalid address
+
+ InvalidWrite
+
+ write of an invalid address
+
+ InvalidJump
+
+ jump to an invalid address
+
+ Overlap
+
+ args overlap other otherwise bogus in eg memcpy
+
+ InvalidMemPool
+
+ invalid mem pool specified in client request
+
+ UninitCondition
+
+ conditional jump/move depends on undefined value
+
+ UninitValue
+
+ other use of undefined value (primarily memory addresses)
+
+ SyscallParam
+
+ system call params are undefined or point to
+ undefined/unaddressible memory
+
+ ClientCheck
+
+ "error" resulting from a client check request
+
+ Leak_DefinitelyLost
+
+ memory leak; the referenced blocks are definitely lost
+
+ Leak_IndirectlyLost
+
+ memory leak; the referenced blocks are lost because all pointers
+ to them are also in leaked blocks
+
+ Leak_PossiblyLost
+
+ memory leak; only interior pointers to referenced blocks were
+ found
+
+ Leak_StillReachable
+
+ memory leak; pointers to un-freed blocks are still available
+
+
+ORIGIN
+------
+ORIGIN shows the origin of uninitialised data in errors that involve
+uninitialised data. STACK shows the origin of the uninitialised
+value. TEXT gives a human-understandable hint as to the meaning of
+the information in STACK.
+
+ <origin>
+ <what>TEXT<what>
+ STACK
+ </origin>
+
+
+====================================================================
+
+ERROR definition for Ptrcheck
+-----------------------------
+
+The definition is:
+
+ <error>
+ <unique>HEX64</unique>
+ <tid>INT</tid>
+ <kind>KIND</kind>
+ <what>TEXT</what> (either 1 or 2 times)
+
+ STACK
+
+ zero or more of (STACK or <auxwhat>TEXT</auxwhat>)
+
+ optionally: SUPPRESSION
+ </error>
+
+
+The first four fields and the last field are specified in "ERROR
+definition -- common fields" above. The remaining fields are as
+follows:
+
+* The primary STACK for this error, indicating where it occurred.
+
+* Some error types may have auxiliary information attached, expressed
+ as an arbitrary sequence of (STACK or <auxwhat>TEXT</auxwhat>).
+ These should be presented to the user in the sequence they appear in
+ the file, as they are intended to be read top-to-bottom.
+
+
+KIND for Ptrcheck
+-----------------
+This is a small enumeration indicating roughly the nature of an error.
+The possible values are:
+
+ SorG
+
+ Stack or global array inconsistency (roughly speaking, an
+ overrun of a stack or global array). The <auxwhat> blocks give
+ further details.
+
+ Heap
+
+ Usage of a pointer derived from a heap block, to access
+ outside that heap block
+
+ Arith
+
+ Doing arithmetic on pointers in a way that cannot possibly
+ result in another valid pointer. Eg, adding two pointer values.
+
+ SysParam
+
+ Special case of "Heap", in which the invalidly-addressed memory
+ is presented as an argument to a system call which reads or
+ writes memory.
+
+
+====================================================================
+
+ERROR definition for Helgrind
+-----------------------------
+
+The definition is:
+
+ <error>
+ <unique>HEX64</unique>
+ <tid>INT</tid>
+ <kind>KIND</kind>
+ <what>TEXT</what> (either 1 or 2 times)
+
+ STACK
+
+ zero or more of (STACK or <auxwhat>TEXT</auxwhat>)
+
+ optionally: SUPPRESSION
+ </error>
+
+
+The first four fields and the last field are specified in "ERROR
+definition -- common fields" above. The remaining fields are as
+follows:
+
+* The primary STACK for this error, indicating where it occurred.
+
+* Some error types may have auxiliary information attached, expressed
+ as an arbitrary sequence of (STACK or <auxwhat>TEXT</auxwhat>).
+ These should be presented to the user in the sequence they appear in
+ the file, as they are intended to be read top-to-bottom.
+
+
+KIND for Helgrind
+-----------------
+This is a small enumeration indicating roughly the nature of an error.
+The possible values are:
+
+ Race
+
+ Data race. Helgrind will try to show the stacks for both
+ conflicting accesses if it can; it will always show the stack
+ for at least one of them.
+
+ UnlockUnlocked
+
+ Unlocking a not-locked lock
+
+ UnlockForeign
+
+ Unlocking a lock held by some other thread
+
+ UnlockBogus
+
+ Unlocking an address which is not known to be a lock
+
+ PthAPIerror
+
+ One of the POSIX pthread_ functions that are intercepted
+ by Helgrind, failed with an error code. Usually indicates
+ something bad happening.
+
+ LockOrder
+
+ An inconsistency in the acquisition order of locks was observed;
+ dangerous, as it can potentially lead to deadlocks
+
+ Misc
+
+ One of various miscellaneous noteworthy conditions was observed
+ (eg, thread exited whilst holding locks, "impossible" behaviour
+ from the underlying threading library, etc)
Modified: branches/MESSAGING_TIDYUP/docs/internals/xml-output.txt
===================================================================
--- branches/MESSAGING_TIDYUP/docs/internals/xml-output.txt 2009-05-13 08:25:56 UTC (rev 9841)
+++ branches/MESSAGING_TIDYUP/docs/internals/xml-output.txt 2009-05-13 08:34:15 UTC (rev 9842)
@@ -1,4 +1,17 @@
+Note, 11 May 2009. The XML format evolved over several versions,
+as expected. This file describes 3 different versions of the
+format (called Protocols 1, 2 and 3 respectively). As of 11 May 09
+a fourth version, Protocol 4, was defined, and that is described
+in xml-output-protocol4.txt.
+
+The original May 2005 introduction follows. These comments are
+correct up to and including Protocol 3, which was used in the Valgrind
+3.4.x series. However, there were some more significant changes in
+the format and the required flags for Valgrind, in Protocol 4.
+
+ ----------------------
+
As of May 2005, Valgrind can produce its output in XML form. The
intention is to provide an easily parsed, stable format which is
suitable for GUIs to read.
@@ -13,7 +26,7 @@
that investments in parser-writing by GUI developers is not lost as
new versions of Valgrind appear.
-* Have an extensive output format, so that future changes to the
+* Have an extensible output format, so that future changes to the
format do not break backwards compatibility with existing parsers of
it.
@@ -30,7 +43,7 @@
How to use
~~~~~~~~~~
-Run with flag --xml=yes. That`s all. Note however several
+Run with flag --xml=yes. That's all. Note however several
caveats.
* At the present time only Memcheck is supported. The scheme extends
@@ -98,7 +111,7 @@
Inside that, the first entity is an indication of the protocol
version. This is provided so that existing parsers can identify XML
created by future versions of Valgrind merely by observing that the
-protocol version is one they don`t understand. Hence TOPLEVEL is:
+protocol version is one they don't understand. Hence TOPLEVEL is:
<?xml version="1.0"?>
<valgrindoutput>
|
|
From: <sv...@va...> - 2009-05-13 08:26:11
|
Author: sewardj Date: 2009-05-13 09:25:56 +0100 (Wed, 13 May 2009) New Revision: 9841 Log: Update flags needed to make these tests run correctly. Modified: branches/MESSAGING_TIDYUP/memcheck/tests/long_namespace_xml.vgtest branches/MESSAGING_TIDYUP/memcheck/tests/xml1.vgtest Modified: branches/MESSAGING_TIDYUP/memcheck/tests/long_namespace_xml.vgtest =================================================================== --- branches/MESSAGING_TIDYUP/memcheck/tests/long_namespace_xml.vgtest 2009-05-13 08:24:24 UTC (rev 9840) +++ branches/MESSAGING_TIDYUP/memcheck/tests/long_namespace_xml.vgtest 2009-05-13 08:25:56 UTC (rev 9841) @@ -1,3 +1,3 @@ prog: long_namespace_xml -vgopts: --xml=yes +vgopts: --xml=yes --xml-fd=2 --log-file=/dev/null stderr_filter: filter_xml Modified: branches/MESSAGING_TIDYUP/memcheck/tests/xml1.vgtest =================================================================== --- branches/MESSAGING_TIDYUP/memcheck/tests/xml1.vgtest 2009-05-13 08:24:24 UTC (rev 9840) +++ branches/MESSAGING_TIDYUP/memcheck/tests/xml1.vgtest 2009-05-13 08:25:56 UTC (rev 9841) @@ -1,3 +1,3 @@ prog: xml1 -vgopts: --xml=yes +vgopts: --xml=yes --xml-fd=2 --log-file=/dev/null stderr_filter: filter_xml |
|
From: <sv...@va...> - 2009-05-13 08:24:37
|
Author: sewardj
Date: 2009-05-13 09:24:24 +0100 (Wed, 13 May 2009)
New Revision: 9840
Log:
Comment/layout changes (w.r.t. XML printing) only.
Modified:
branches/MESSAGING_TIDYUP/exp-ptrcheck/pc_common.c
Modified: branches/MESSAGING_TIDYUP/exp-ptrcheck/pc_common.c
===================================================================
--- branches/MESSAGING_TIDYUP/exp-ptrcheck/pc_common.c 2009-05-13 08:23:34 UTC (rev 9839)
+++ branches/MESSAGING_TIDYUP/exp-ptrcheck/pc_common.c 2009-05-13 08:24:24 UTC (rev 9840)
@@ -256,8 +256,8 @@
// //
//////////////////////////////////////////////////////////////
-/* Do a printf-style op (with a trailing \n) on either the XML or
- normal output channel, depending on the setting of VG_(clo_xml).
+/* Do a printf-style operation on either the XML or normal output
+ channel, depending on the setting of VG_(clo_xml).
*/
static void emit_WRK ( HChar* format, va_list vargs )
{
@@ -267,7 +267,6 @@
VG_(vmessage)(Vg_UserMsg, format, vargs);
}
}
-
static void emit ( HChar* format, ... ) PRINTF_CHECK(1, 2);
static void emit ( HChar* format, ... )
{
@@ -277,6 +276,7 @@
va_end(vargs);
}
+
static Char* readwrite(SSizeT sszB)
{
return ( sszB < 0 ? "write" : "read" );
|
|
From: <sv...@va...> - 2009-05-13 08:23:45
|
Author: sewardj
Date: 2009-05-13 09:23:34 +0100 (Wed, 13 May 2009)
New Revision: 9839
Log:
Fix XMLisation of leak messages; also a couple of comment/layout changes.
Modified:
branches/MESSAGING_TIDYUP/memcheck/mc_errors.c
Modified: branches/MESSAGING_TIDYUP/memcheck/mc_errors.c
===================================================================
--- branches/MESSAGING_TIDYUP/memcheck/mc_errors.c 2009-05-13 08:22:00 UTC (rev 9838)
+++ branches/MESSAGING_TIDYUP/memcheck/mc_errors.c 2009-05-13 08:23:34 UTC (rev 9839)
@@ -258,8 +258,8 @@
/*--- Printing errors ---*/
/*------------------------------------------------------------*/
-/* Do a printf-style op (with a trailing \n) on either the XML or
- normal output channel, depending on the setting of VG_(clo_xml).
+/* Do a printf-style operation on either the XML or normal output
+ channel, depending on the setting of VG_(clo_xml).
*/
static void emit_WRK ( HChar* format, va_list vargs )
{
@@ -269,7 +269,6 @@
VG_(vmessage)(Vg_UserMsg, format, vargs);
}
}
-
static void emit ( HChar* format, ... ) PRINTF_CHECK(1, 2);
static void emit ( HChar* format, ... )
{
@@ -278,7 +277,6 @@
emit_WRK(format, vargs);
va_end(vargs);
}
-
static void emit_no_f_c ( HChar* format, ... )
{
va_list vargs;
@@ -419,9 +417,7 @@
static void mc_pp_origin ( ExeContext* ec, UInt okind )
{
- HChar* src = NULL;
- HChar* xpre = VG_(clo_xml) ? " <what>" : " ";
- HChar* xpost = VG_(clo_xml) ? "</what>" : "";
+ HChar* src = NULL;
tl_assert(ec);
switch (okind) {
@@ -432,14 +428,14 @@
}
tl_assert(src); /* guards against invalid 'okind' */
- if (VG_(clo_xml)) {
+ if (VG_(clo_xml)) {
VG_(printf_xml)(" <origin>\n");
- VG_(printf_xml)("%sUninitialised value was created%s%s",
- xpre, src, xpost);
+ VG_(printf_xml)("<what>Uninitialised value was created%s</what>",
+ src);
VG_(pp_ExeContext)( ec );
VG_(printf_xml)(" </origin>\n");
} else {
- VG_(message)(Vg_UserMsg, "Uninitialised value was created%s\n",
+ VG_(message)(Vg_UserMsg, " Uninitialised value was created%s\n",
src);
VG_(pp_ExeContext)( ec );
}
@@ -596,14 +592,14 @@
LossRecord* lr = extra->Err.Leak.lr;
if (VG_(clo_xml)) {
- VG_(message_no_f_c)(Vg_UserMsg, " <kind>%t</kind>\n",
- xml_leak_kind(lr->key.state));
+ VG_(printf_xml_no_f_c)(" <kind>%t</kind>\n",
+ xml_leak_kind(lr->key.state));
} else {
VG_(message)(Vg_UserMsg, "\n");
}
if (lr->indirect_szB > 0) {
- VG_(message)(Vg_UserMsg,
+ emit(
"%s%'lu (%'lu direct, %'lu indirect) bytes in %'u blocks"
" are %s in loss record %'u of %'u%s\n",
xpre,
@@ -614,14 +610,13 @@
);
if (VG_(clo_xml)) {
// Nb: don't put commas in these XML numbers
- VG_(message)(Vg_UserMsg, " <leakedbytes>%lu</leakedbytes>\n",
- lr->szB + lr->indirect_szB);
- VG_(message)(Vg_UserMsg, " <leakedblocks>%u</leakedblocks>\n",
- lr->num_blocks);
+ VG_(printf_xml)(" <leakedbytes>%lu</leakedbytes>\n",
+ lr->szB + lr->indirect_szB);
+ VG_(printf_xml)(" <leakedblocks>%u</leakedblocks>\n",
+ lr->num_blocks);
}
} else {
- VG_(message)(
- Vg_UserMsg,
+ emit(
"%s%'lu bytes in %'u blocks are %s in loss record %'u of %'u%s\n",
xpre,
lr->szB, lr->num_blocks,
@@ -629,10 +624,10 @@
xpost
);
if (VG_(clo_xml)) {
- VG_(message)(Vg_UserMsg, " <leakedbytes>%ld</leakedbytes>\n",
- lr->szB);
- VG_(message)(Vg_UserMsg, " <leakedblocks>%d</leakedblocks>\n",
- lr->num_blocks);
+ VG_(printf_xml)(" <leakedbytes>%ld</leakedbytes>\n",
+ lr->szB);
+ VG_(printf_xml)(" <leakedblocks>%d</leakedblocks>\n",
+ lr->num_blocks);
}
}
VG_(pp_ExeContext)(lr->key.allocated_at);
|
|
From: <sv...@va...> - 2009-05-13 08:22:16
|
Author: sewardj
Date: 2009-05-13 09:22:00 +0100 (Wed, 13 May 2009)
New Revision: 9838
Log:
Bump the generated XML's protocol version number to 4.
Modified:
branches/MESSAGING_TIDYUP/coregrind/m_main.c
Modified: branches/MESSAGING_TIDYUP/coregrind/m_main.c
===================================================================
--- branches/MESSAGING_TIDYUP/coregrind/m_main.c 2009-05-13 08:20:02 UTC (rev 9837)
+++ branches/MESSAGING_TIDYUP/coregrind/m_main.c 2009-05-13 08:22:00 UTC (rev 9838)
@@ -926,7 +926,8 @@
VG_(printf_xml)("\n");
VG_(printf_xml)("<valgrindoutput>\n");
VG_(printf_xml)("\n");
- VG_(printf_xml)("<protocolversion>3</protocolversion>\n");
+ VG_(printf_xml)("<protocolversion>4</protocolversion>\n");
+ VG_(printf_xml)("<protocoltool>%s</protocoltool>\n", toolname);
VG_(printf_xml)("\n");
}
@@ -2243,6 +2244,8 @@
//--------------------------------------------------------------
if (VG_(clo_verbosity) > 0)
VG_(message)(Vg_UserMsg, "\n");
+ if (VG_(clo_xml))
+ VG_(printf_xml)("\n");
if (VG_(clo_xml)) {
HChar buf[50];
|
|
From: <sv...@va...> - 2009-05-13 08:20:16
|
Author: sewardj Date: 2009-05-13 09:20:02 +0100 (Wed, 13 May 2009) New Revision: 9837 Log: Add the ability to print, in XML form, the a suppression at the end of each error. See https://bugs.kde.org/show_bug.cgi?id=191189. Requires some rather inelegant dodging and weaving around the normal error-printing logic. Modified: branches/MESSAGING_TIDYUP/coregrind/m_errormgr.c Modified: branches/MESSAGING_TIDYUP/coregrind/m_errormgr.c =================================================================== --- branches/MESSAGING_TIDYUP/coregrind/m_errormgr.c 2009-05-11 11:34:49 UTC (rev 9836) +++ branches/MESSAGING_TIDYUP/coregrind/m_errormgr.c 2009-05-13 08:20:02 UTC (rev 9837) @@ -286,6 +286,11 @@ } } +/* This prints an error, either in text or XML mode. Note that in XML + mode, it does not print the trailing </error> tag. That is so as + to allow callers to print more stuff (specificially, an XML-form + suppression for the error, by calling do_actions_on_error) before + the closing tag. */ static void pp_Error ( Error* err ) { if (VG_(clo_xml)) { @@ -319,8 +324,10 @@ } } - if (VG_(clo_xml)) - VG_(printf_xml)("</error>\n"); + // No .. the caller must do this. See comment at the start of + // this fn. + //if (VG_(clo_xml)) + // VG_(printf_xml)("</error>\n"); } /* Figure out if we want to perform a given action for this error, possibly @@ -404,11 +411,22 @@ static UChar buf[ERRTXT_LEN]; if ( VG_(get_fnname_no_cxx_demangle) (ip, buf, ERRTXT_LEN) ) { - VG_(printf)(" fun:%s\n", buf); - } else if ( VG_(get_objname)(ip, buf, ERRTXT_LEN) ) { - VG_(printf)(" obj:%s\n", buf); + if (VG_(clo_xml)) + VG_(printf_xml_no_f_c)(" <sframe> <fun>%t</fun> </sframe>\n", buf); + else + VG_(printf)(" fun:%s\n", buf); + + } else if ( VG_(get_objname)(ip, buf, ERRTXT_LEN) ) { + if (VG_(clo_xml)) + VG_(printf_xml_no_f_c)(" <sframe> <obj>%t</obj> </sframe>\n", buf); + else + VG_(printf)(" obj:%s\n", buf); + } else { - VG_(printf)(" obj:*\n"); + if (VG_(clo_xml)) + VG_(printf_xml_no_f_c)(" <sframe> <obj>*</obj> </sframe>\n"); + else + VG_(printf)(" obj:*\n"); } } @@ -416,7 +434,7 @@ { ExeContext* ec = VG_(get_error_where)(err); - //(example code, see comment on CoreSuppKind above) + //(example code, see comment on CoreSuppKind above) if (0) { //if (0) ThreadErr == err->ekind) { // VG_(printf)("{\n"); @@ -430,9 +448,15 @@ VG_(details).name); return; } - VG_(printf)("{\n"); - VG_(printf)(" <insert a suppression name here>\n"); - VG_(printf)(" %s:%s\n", VG_(details).name, name); + if (VG_(clo_xml)) { + VG_(printf_xml)(" <suppression>\n"); + VG_(printf_xml)(" <sname>insert_a_suppression_name_here</sname>\n"); + VG_(printf_xml)(" <skind>%s:%s</skind>\n", VG_(details).name, name); + } else { + VG_(printf)("{\n"); + VG_(printf)(" <insert a suppression name here>\n"); + VG_(printf)(" %s:%s\n", VG_(details).name, name); + } VG_TDICT_CALL(tool_print_extra_suppression_info, err); } @@ -441,7 +465,11 @@ VG_(get_ExeContext_StackTrace)(ec), VG_(get_ExeContext_n_ips)(ec)); - VG_(printf)("}\n"); + if (VG_(clo_xml)) { + VG_(printf_xml)(" </suppression>\n"); + } else { + VG_(printf)("}\n"); + } } static @@ -633,6 +661,10 @@ is_first_shown_context = False; n_errs_shown++; do_actions_on_error(p, /*allow_db_attach*/True); + // Finish up the <error> block started by the call to pp_Error. See + // comments on pp_Error for why pp_Error does not do this itself. + if (VG_(clo_xml)) + VG_(printf_xml)("</error>\n"); } else { n_errs_suppressed++; p->supp->count++; @@ -671,12 +703,20 @@ n_errs_found++; if (print_error) { - if (!is_first_shown_context) - VG_(UMSG)("\n"); + if (!is_first_shown_context) { + if (VG_(clo_xml)) + VG_(printf_xml)("\n"); + else + VG_(UMSG)("\n"); + } pp_Error(&err); is_first_shown_context = False; n_errs_shown++; do_actions_on_error(&err, allow_db_attach); + // Finish up the <error> block started by the call to pp_Error. See + // comments on pp_Error for why pp_Error does not do this itself. + if (VG_(clo_xml)) + VG_(printf_xml)("</error>\n"); } return False; @@ -783,6 +823,10 @@ VG_(UMSG)("%d errors in context %d of %d:\n", p_min->count, i+1, n_err_contexts); pp_Error( p_min ); + // Finish up the <error> block started by the call to pp_Error. See + // comments on pp_Error for why pp_Error does not do this itself. + // Except, we're not printing XML -- we'd have exited above if so. + vg_assert(! VG_(clo_xml)); if ((i+1 == VG_(clo_dump_error))) { StackTrace ips = VG_(get_ExeContext_StackTrace)(p_min->where); |