tests: set up nightly regression tests #11
Comments
|
From [email protected] on February 24, 2009 07:42:13 xref issue #36 : we want a nightly regression of our release package build env |
|
From [email protected] on March 03, 2009 15:15:56 xref issue #65 : if we get ctest set up we can use its integration with Dash for |
|
From [email protected] on August 09, 2009 08:28:21 r199 has basic support here:
leaving issue open for setting up cron jobs on some machines, setting up emails on |
|
From [email protected] on August 09, 2009 12:12:32 in r200 :
on glaurung short takes 3:45, long takes 15:51 leaving issue open for:
|
|
From [email protected] on October 25, 2011 19:04:51 We've more or less handled this with the Chromium buildbot infrastructure: http://build.chromium.org/p/client.drmemory/ One issue is that the nightly test results are currently meaningless, they are summarized as 429/429 tests failed. It seems that something is not parsing something else's output right somewhere in the summary process, looking at the summary: http://build.chromium.org/p/client.drmemory/builders/linux-lucid_x64-dr_nightly/builds/112/steps/Run%20DR%20nightly%20suite/logs/summary%3A%20429%20test%28s%29%20failed We also might like to set up builders that run on Fedora or with older kernels if we want to make sure we don't break support for them. Both of these things are separate issues IMO, so I'll mark this closed for now. Reopen if you feel this isn't fully addressed. Status: Fixed |
…32. (#6747) tool.drcachesim.invariant_checker_test fails on x86-32 with the following error: 1/371 Test #11: tool.drcachesim.invariant_checker_test ...........................***Failed 0.04 sec Recording |Too many read records| in T1 @ ref # 16 (6 instrs since timestamp 0) Recording |Too many read records| in T1 @ ref # 17 (6 instrs since timestamp 0) Recording |Too many read records| in T1 @ ref # 18 (6 instrs since timestamp 0) Recording |Too many read records| in T1 @ ref # 19 (6 instrs since timestamp 0) Recording |Too many write records| in T1 @ ref # 21 (7 instrs since timestamp 0) Recording |Too many write records| in T1 @ ref # 22 (7 instrs since timestamp 0) Recording |Too many write records| in T1 @ ref # 23 (7 instrs since timestamp 0) Recording |Too many write records| in T1 @ ref # 24 (7 instrs since timestamp 0) Unexpected error: Too many read records at ref: 16 Unexpected error: Too many read records at ref: 17 Unexpected error: Too many read records at ref: 18 Unexpected error: Too many read records at ref: 19 Unexpected error: Too many write records at ref: 21 Unexpected error: Too many write records at ref: 22 Unexpected error: Too many write records at ref: 23 Unexpected error: Too many write records at ref: 24 OP_xsaves64 and OP_xrstors32 are marked as o64 (X86_INVALID) in core/ir/x86/decode_table.c. instr_is_xsave() and instr_is_xrstor() return false on x86-32, hence not skipping the number of read/write record check in the invariant check on x86_32. Use xrstors32 and xsaves32 instead for the test on x86_32. Fixes #6744
From [email protected] on February 14, 2009 10:30:29
If we can procure cycles on machines somewhere we should set up nightly or
bi-nightly regression tests.
Our tests at Determina used to take over 24 hours. After issue #8 prunes
them to target just the API they should get shorter.
For a first pass we should have:
Due to missing WOW64 follow-children (issue to be file: xref issue #3 ) we
can't do full 32-bit testing on a 64-bit Windows machine.
Ideally we should have at least one machine with some flavor of Windows NT,
Windows 2000, Windows XP, Windows 2003, and Windows Vista, in each of
32-bit and for the later ones 64-bit, along with several flavors of Linux,
and both AMD and Intel processors of several varieties. We can use virtual
machines for nearly all our tests but it would be nice to have nightly
performance tests on native machines.
We should also have at least one 64-bit Linux and one 64-bit Windows
machine that can run a pre-commit regression test on demand for use by
developers who do not have one of each flavor locally available.
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=11
The text was updated successfully, but these errors were encountered: