| __init__.py |
|
0 |
| cross-architecture.sup |
|
4361 |
| i386-pc-linux-gnu.sup |
|
768 |
| mach_commands.py |
Must be a build with --enable-valgrind and --disable-jemalloc. |
9533 |
| output_handler.py |
A class for handling Valgrind output.
Valgrind errors look like this:
==60741== 40 (24 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 2,746 of 5,235
==60741== at 0x4C26B43: calloc (vg_replace_malloc.c:593)
==60741== by 0x63AEF65: PR_Calloc (prmem.c:443)
==60741== by 0x69F236E: PORT_ZAlloc_Util (secport.c:117)
==60741== by 0x69F1336: SECITEM_AllocItem_Util (secitem.c:28)
==60741== by 0xA04280B: ffi_call_unix64 (in /builds/slave/m-in-l64-valgrind-000000000000/objdir/toolkit/library/libxul.so)
==60741== by 0xA042443: ffi_call (ffi64.c:485)
For each such error, this class extracts most or all of the first (error
kind) line, plus the function name in each of the first few stack entries.
With this data it constructs and prints a TEST-UNEXPECTED-FAIL message that
TBPL will highlight.
It buffers these lines from which text is extracted so that the
TEST-UNEXPECTED-FAIL message can be printed before the full error.
Parsing the Valgrind output isn't ideal, and it may break in the future if
Valgrind changes the format of the messages, or introduces new error kinds.
To protect against this, we also count how many lines containing
"<insert_a_suppression_name_here>" are seen. Thanks to the use of
--gen-suppressions=yes, exactly one of these lines is present per error. If
the count of these lines doesn't match the error count found during
parsing, then the parsing has missed one or more errors and we can fail
appropriately.
|
5290 |
| x86_64-pc-linux-gnu.sup |
|
40380 |