sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 1 | |
| 2 | As of May 2005, Valgrind can produce its output in XML form. The |
| 3 | intention is to provide an easily parsed, stable format which is |
| 4 | suitable for GUIs to read. |
| 5 | |
| 6 | |
| 7 | Design goals |
| 8 | ~~~~~~~~~~~~ |
| 9 | |
| 10 | * Produce XML output which is easily parsed |
| 11 | |
| 12 | * Have a stable output format which does not change much over time, so |
| 13 | that investments in parser-writing by GUI developers is not lost as |
| 14 | new versions of Valgrind appear. |
| 15 | |
| 16 | * Have an extensive output format, so that future changes to the |
| 17 | format do not break backwards compatibility with existing parsers of |
| 18 | it. |
| 19 | |
| 20 | * Produce output in a form which suitable for both offline GUIs (run |
| 21 | all the way to the end, then examine output) and interactive GUIs |
| 22 | (parse XML incrementally, update display as we go). |
| 23 | |
| 24 | * Put as much information as possible into the XML and let the GUIs |
| 25 | decide what to show the user (a.k.a provide mechanism, not policy). |
| 26 | |
sewardj | 57d99c5 | 2005-06-13 16:44:33 +0000 | [diff] [blame] | 27 | * Make XML which is actually parseable by standard XML tools. |
| 28 | |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 29 | |
| 30 | How to use |
| 31 | ~~~~~~~~~~ |
| 32 | |
de | e6ca7bd | 2005-08-03 18:58:45 +0000 | [diff] [blame] | 33 | Run with flag --xml=yes. That`s all. Note however several |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 34 | caveats. |
| 35 | |
| 36 | * At the present time only Memcheck is supported. The scheme extends |
njn | 1d0825f | 2006-03-27 11:37:07 +0000 | [diff] [blame] | 37 | easily enough to cover Helgrind if needed. |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 38 | |
| 39 | * When XML output is selected, various other settings are made. |
| 40 | This is in order that the output format is more controlled. |
| 41 | The settings which are changed are: |
| 42 | |
| 43 | - Suppression generation is disabled, as that would require user |
| 44 | input. |
| 45 | |
| 46 | - Attaching to GDB is disabled for the same reason. |
| 47 | |
| 48 | - The verbosity level is set to 1 (-v). |
| 49 | |
| 50 | - Error limits are disabled. Usually if the program generates a lot |
| 51 | of errors, Valgrind slows down and eventually stops collecting |
| 52 | them. When outputting XML this is not the case. |
| 53 | |
| 54 | - VEX emulation warnings are not shown. |
| 55 | |
| 56 | - File descriptor leak checking is disabled. This could be |
| 57 | re-enabled at some future point. |
| 58 | |
| 59 | - Maximum-detail leak checking is selected (--leak-check=full). |
| 60 | |
| 61 | |
| 62 | The output format |
| 63 | ~~~~~~~~~~~~~~~~~ |
sewardj | 9e7212f | 2005-05-24 15:00:55 +0000 | [diff] [blame] | 64 | For the most part this should be self descriptive. It is printed in a |
| 65 | sort-of human-readable way for easy understanding. You may want to |
| 66 | read the rest of this together with the results of "valgrind --xml=yes |
| 67 | memcheck/tests/xml1" as an example. |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 68 | |
| 69 | All tags are balanced: a <foo> tag is always closed by </foo>. Hence |
| 70 | in the description that follows, mention of a tag <foo> implicitly |
| 71 | means there is a matching closing tag </foo>. |
| 72 | |
| 73 | Symbols in CAPITALS are nonterminals in the grammar and are defined |
| 74 | somewhere below. The root nonterminal is TOPLEVEL. |
| 75 | |
| 76 | The following nonterminals are not described further: |
| 77 | INT is a 64-bit signed decimal integer. |
| 78 | TEXT is arbitrary text. |
sewardj | 9e7212f | 2005-05-24 15:00:55 +0000 | [diff] [blame] | 79 | HEX64 is a 64-bit hexadecimal number, with leading "0x". |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 80 | |
sewardj | 57d99c5 | 2005-06-13 16:44:33 +0000 | [diff] [blame] | 81 | Text strings are escaped so as to remove the <, > and & characters |
| 82 | which would otherwise mess up parsing. They are replaced respectively |
| 83 | with the standard encodings "<", ">" and "&" respectively. |
| 84 | Note this is not (yet) done throughout, only for function names in |
| 85 | <frame>..</frame> tags-pairs. |
| 86 | |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 87 | |
| 88 | TOPLEVEL |
| 89 | -------- |
sewardj | 57d99c5 | 2005-06-13 16:44:33 +0000 | [diff] [blame] | 90 | |
| 91 | The first line output is always this: |
| 92 | |
| 93 | <?xml version="1.0"?> |
| 94 | |
| 95 | All remaining output is contained within the tag-pair |
| 96 | <valgrindoutput>. |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 97 | |
| 98 | Inside that, the first entity is an indication of the protocol |
| 99 | version. This is provided so that existing parsers can identify XML |
| 100 | created by future versions of Valgrind merely by observing that the |
de | e6ca7bd | 2005-08-03 18:58:45 +0000 | [diff] [blame] | 101 | protocol version is one they don`t understand. Hence TOPLEVEL is: |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 102 | |
sewardj | 8665d8e | 2005-06-01 17:35:23 +0000 | [diff] [blame] | 103 | <?xml version="1.0"?> |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 104 | <valgrindoutput> |
| 105 | <protocolversion>INT<protocolversion> |
sewardj | 6a5a69c | 2005-11-17 00:51:36 +0000 | [diff] [blame] | 106 | PROTOCOL |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 107 | </valgrindoutput> |
| 108 | |
sewardj | 6a5a69c | 2005-11-17 00:51:36 +0000 | [diff] [blame] | 109 | Valgrind versions 3.0.0 and 3.0.1 emit protocol version 1. Version |
| 110 | 3.1.0 emits protocol version 2. |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 111 | |
| 112 | |
sewardj | 6a5a69c | 2005-11-17 00:51:36 +0000 | [diff] [blame] | 113 | PROTOCOL for version 2 |
| 114 | ---------------------- |
| 115 | Version 2 is identical in every way to version 1, except that the time |
| 116 | string in |
| 117 | |
| 118 | <time>human-readable-time-string</time> |
| 119 | |
| 120 | has changed format, and is also elapsed wallclock time since process |
| 121 | start, and not local time or any such. In fact version 1 does not |
| 122 | define the format of the string so in some ways this revision is |
| 123 | irrelevant. |
| 124 | |
| 125 | |
| 126 | PROTOCOL for version 1 |
| 127 | ---------------------- |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 128 | This is the main top-level construction. Roughly speaking, it |
| 129 | contains a load of preamble, the errors from the run of the |
| 130 | program, and the result of the final leak check. Hence the |
| 131 | following in sequence: |
| 132 | |
| 133 | * Various preamble lines which give version info for the various |
| 134 | components. The text in them can be anything; it is not intended |
| 135 | for interpretation by the GUI: |
| 136 | |
sewardj | 57d99c5 | 2005-06-13 16:44:33 +0000 | [diff] [blame] | 137 | <preamble> |
| 138 | <line>Misc version/copyright text</line> (zero or more of) |
| 139 | </preamble> |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 140 | |
| 141 | * The PID of this process and of its parent: |
| 142 | |
| 143 | <pid>INT</pid> |
| 144 | <ppid>INT</ppid> |
| 145 | |
| 146 | * The name of the tool being used: |
| 147 | |
| 148 | <tool>TEXT</tool> |
| 149 | |
sewardj | ad31116 | 2005-07-19 11:25:02 +0000 | [diff] [blame] | 150 | * OPTIONALLY, if --log-file-qualifier=VAR flag was given: |
| 151 | |
| 152 | <logfilequalifier> <var>VAR</var> <value>$VAR</value> |
| 153 | </logfilequalifier> |
| 154 | |
| 155 | That is, both the name of the environment variable and its value |
| 156 | are given. |
njn | 374a36d | 2007-11-23 01:41:32 +0000 | [diff] [blame] | 157 | [update: as of v3.3.0, this is not present, as the --log-file-qualifier |
| 158 | option has been removed, replaced by the %q format specifier in --log-file.] |
sewardj | ad31116 | 2005-07-19 11:25:02 +0000 | [diff] [blame] | 159 | |
sewardj | e5e1f82 | 2005-07-19 14:59:41 +0000 | [diff] [blame] | 160 | * OPTIONALLY, if --xml-user-comment=STRING was given: |
| 161 | |
| 162 | <usercomment>STRING</usercomment> |
| 163 | |
| 164 | STRING is not escaped in any way, so that it itself may be a piece |
| 165 | of XML with arbitrary tags etc. |
| 166 | |
sewardj | b8a3dac | 2005-07-19 12:39:11 +0000 | [diff] [blame] | 167 | * The program and args: first those pertaining to Valgrind itself, and |
| 168 | then those pertaining to the program to be run under Valgrind (the |
| 169 | client): |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 170 | |
sewardj | b8a3dac | 2005-07-19 12:39:11 +0000 | [diff] [blame] | 171 | <args> |
| 172 | <vargv> |
| 173 | <exe>TEXT</exe> |
| 174 | <arg>TEXT</arg> (zero or more of) |
| 175 | </vargv> |
| 176 | <argv> |
| 177 | <exe>TEXT</exe> |
| 178 | <arg>TEXT</arg> (zero or more of) |
| 179 | </argv> |
| 180 | </args> |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 181 | |
| 182 | * The following, indicating that the program has now started: |
| 183 | |
sewardj | 33e6042 | 2005-07-24 07:33:15 +0000 | [diff] [blame] | 184 | <status> <state>RUNNING</state> |
| 185 | <time>human-readable-time-string</time> |
sewardj | 68cde6f | 2005-07-19 12:17:51 +0000 | [diff] [blame] | 186 | </status> |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 187 | |
| 188 | * Zero or more of (either ERROR or ERRORCOUNTS). |
| 189 | |
| 190 | * The following, indicating that the program has now finished, and |
| 191 | that the wrapup (leak checking) is happening. |
| 192 | |
sewardj | 33e6042 | 2005-07-24 07:33:15 +0000 | [diff] [blame] | 193 | <status> <state>FINISHED</state> |
| 194 | <time>human-readable-time-string</time> |
sewardj | 68cde6f | 2005-07-19 12:17:51 +0000 | [diff] [blame] | 195 | </status> |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 196 | |
| 197 | * SUPPCOUNTS, indicating how many times each suppression was used. |
| 198 | |
| 199 | * Zero or more ERRORs, each of which is a complaint from the |
| 200 | leak checker. |
| 201 | |
sewardj | 6a5a69c | 2005-11-17 00:51:36 +0000 | [diff] [blame] | 202 | That's it. |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 203 | |
| 204 | |
| 205 | ERROR |
| 206 | ----- |
| 207 | This shows an error, and is the most complex nonterminal. The format |
| 208 | is as follows: |
| 209 | |
| 210 | <error> |
| 211 | <unique>HEX64</unique> |
| 212 | <tid>INT</tid> |
| 213 | <kind>KIND</kind> |
| 214 | <what>TEXT</what> |
| 215 | |
| 216 | optionally: <leakedbytes>INT</leakedbytes> |
| 217 | optionally: <leakedblocks>INT</leakedblocks> |
| 218 | |
| 219 | STACK |
| 220 | |
| 221 | optionally: <auxwhat>TEXT</auxwhat> |
| 222 | optionally: STACK |
| 223 | |
| 224 | </error> |
| 225 | |
| 226 | * Each error contains a unique, arbitrary 64-bit hex number. This is |
| 227 | used to refer to the error in ERRORCOUNTS nonterminals (see below). |
| 228 | |
| 229 | * The <tid> tag indicates the Valgrind thread number. This value |
| 230 | is arbitrary but may be used to determine which threads produced |
| 231 | which errors (at least, the first instance of each error). |
| 232 | |
| 233 | * The <kind> tag specifies one of a small number of fixed error |
| 234 | types (enumerated below), so that GUIs may roughly categorise |
| 235 | errors by type if they want. |
| 236 | |
| 237 | * The <what> tag gives a human-understandable description of the |
| 238 | error. |
| 239 | |
| 240 | * For <kind> tags specifying a KIND of the form "Leak_*", the |
| 241 | optional <leakedbytes> and <leakedblocks> indicate the number of |
| 242 | bytes and blocks leaked by this error. |
| 243 | |
| 244 | * The primary STACK for this error, indicating where it occurred. |
| 245 | |
| 246 | * Some error types may have auxiliary information attached: |
| 247 | |
| 248 | <auxwhat>TEXT</auxwhat> gives an auxiliary human-readable |
| 249 | description (usually of invalid addresses) |
| 250 | |
| 251 | STACK gives an auxiliary stack (usually the allocation/free |
| 252 | point of a block). If this STACK is present then |
| 253 | <auxwhat>TEXT</auxwhat> will precede it. |
| 254 | |
| 255 | |
| 256 | KIND |
| 257 | ---- |
| 258 | This is a small enumeration indicating roughly the nature of an error. |
| 259 | The possible values are: |
| 260 | |
| 261 | InvalidFree |
| 262 | |
| 263 | free/delete/delete[] on an invalid pointer |
| 264 | |
| 265 | MismatchedFree |
| 266 | |
| 267 | free/delete/delete[] does not match allocation function |
| 268 | (eg doing new[] then free on the result) |
| 269 | |
| 270 | InvalidRead |
| 271 | |
| 272 | read of an invalid address |
| 273 | |
| 274 | InvalidWrite |
| 275 | |
| 276 | write of an invalid address |
| 277 | |
| 278 | InvalidJump |
| 279 | |
| 280 | jump to an invalid address |
| 281 | |
| 282 | Overlap |
| 283 | |
| 284 | args overlap other otherwise bogus in eg memcpy |
| 285 | |
| 286 | InvalidMemPool |
| 287 | |
| 288 | invalid mem pool specified in client request |
| 289 | |
| 290 | UninitCondition |
| 291 | |
| 292 | conditional jump/move depends on undefined value |
| 293 | |
| 294 | UninitValue |
| 295 | |
| 296 | other use of undefined value (primarily memory addresses) |
| 297 | |
| 298 | SyscallParam |
| 299 | |
| 300 | system call params are undefined or point to |
| 301 | undefined/unaddressible memory |
| 302 | |
| 303 | ClientCheck |
| 304 | |
| 305 | "error" resulting from a client check request |
| 306 | |
| 307 | Leak_DefinitelyLost |
| 308 | |
| 309 | memory leak; the referenced blocks are definitely lost |
| 310 | |
| 311 | Leak_IndirectlyLost |
| 312 | |
| 313 | memory leak; the referenced blocks are lost because all pointers |
| 314 | to them are also in leaked blocks |
| 315 | |
| 316 | Leak_PossiblyLost |
| 317 | |
| 318 | memory leak; only interior pointers to referenced blocks were |
| 319 | found |
| 320 | |
| 321 | Leak_StillReachable |
| 322 | |
| 323 | memory leak; pointers to un-freed blocks are still available |
| 324 | |
| 325 | |
| 326 | STACK |
| 327 | ----- |
| 328 | STACK indicates locations in the program being debugged. A STACK |
| 329 | is one or more FRAMEs. The first is the innermost frame, the |
| 330 | next its caller, etc. |
| 331 | |
| 332 | <stack> |
| 333 | one or more FRAME |
| 334 | </stack> |
| 335 | |
| 336 | |
| 337 | FRAME |
| 338 | ----- |
| 339 | FRAME records a single program location: |
| 340 | |
| 341 | <frame> |
| 342 | <ip>HEX64</ip> |
| 343 | optionally <obj>TEXT</obj> |
| 344 | optionally <fn>TEXT</fn> |
sewardj | 57d99c5 | 2005-06-13 16:44:33 +0000 | [diff] [blame] | 345 | optionally <dir>TEXT</dir> |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 346 | optionally <file>TEXT</file> |
| 347 | optionally <line>INT</line> |
| 348 | </frame> |
| 349 | |
| 350 | Only the <ip> field is guaranteed to be present. It indicates a |
| 351 | code ("instruction pointer") address. |
| 352 | |
| 353 | The optional fields, if present, appear in the order stated: |
| 354 | |
| 355 | * obj: gives the name of the ELF object containing the code address |
| 356 | |
| 357 | * fn: gives the name of the function containing the code address |
| 358 | |
sewardj | 57d99c5 | 2005-06-13 16:44:33 +0000 | [diff] [blame] | 359 | * dir: gives the source directory associated with the name specified |
| 360 | by <file>. Note the current implementation often does not |
| 361 | put anything useful in this field. |
| 362 | |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 363 | * file: gives the name of the source file containing the code address |
| 364 | |
| 365 | * line: gives the line number in the source file |
| 366 | |
| 367 | |
| 368 | ERRORCOUNTS |
| 369 | ----------- |
| 370 | This specifies, for each error that has been so far presented, |
| 371 | the number of occurrences of that error. |
| 372 | |
| 373 | <errorcounts> |
| 374 | zero or more of |
| 375 | <pair> <count>INT</count> <unique>HEX64</unique> </pair> |
| 376 | </errorcounts> |
| 377 | |
| 378 | Each <pair> gives the current error count <count> for the error with |
| 379 | unique tag </unique>. The counts do not have to give a count for each |
| 380 | error so far presented - partial information is allowable. |
| 381 | |
sewardj | 9e7212f | 2005-05-24 15:00:55 +0000 | [diff] [blame] | 382 | As at Valgrind rev 3793, error counts are only emitted at program |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 383 | termination. However, it is perfectly acceptable to periodically emit |
| 384 | error counts as the program is running. Doing so would facilitate a |
| 385 | GUI to dynamically update its error-count display as the program runs. |
| 386 | |
| 387 | |
| 388 | SUPPCOUNTS |
| 389 | ---------- |
| 390 | A SUPPCOUNTS block appears exactly once, after the program terminates. |
| 391 | It specifies the number of times each error-suppression was used. |
| 392 | Suppressions not mentioned were used zero times. |
| 393 | |
| 394 | <suppcounts> |
| 395 | zero or more of |
sewardj | 7c9e57c | 2005-05-24 14:21:45 +0000 | [diff] [blame] | 396 | <pair> <count>INT</count> <name>TEXT</name> </pair> |
sewardj | 9829e38 | 2005-05-24 14:17:41 +0000 | [diff] [blame] | 397 | </suppcounts> |
| 398 | |
| 399 | The <name> is as specified in the suppression name fields in .supp |
| 400 | files. |
sewardj | 57d99c5 | 2005-06-13 16:44:33 +0000 | [diff] [blame] | 401 | |