|
From: Jeroen N. W. <jn...@xs...> - 2005-05-05 12:10:29
|
Running make regtest in valgrind-svn (vex revision 1159 and valgrind revision 3623) on debian/sarge results in the following errors. == 173 tests, 7 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/writev (stderr) memcheck/tests/x86/scalar (stderr) corecheck/tests/fdleak_fcntl (stderr) none/tests/faultstatus (stderr) none/tests/tls (stdout) none/tests/tls (stderr) none/tests/x86/int (stderr) uname -a returns Linux DoornRoosje 2.4.26-1-386 #1 Tue Aug 24 13:31:19 JST 2004 i686 GNU/Linux memcheck/tests/writev fails because the output does not contain the procedure names (writev, readv, do_writev and do_readv). Ditto for corecheck/tests/fdleak_fcntl and fcntl. memcheck/tests/x86/scalar fails because - line numbers do not match. I removed one line from the source (see previous mails) but the line numbers are off by three. - the format of some stack trace lines has changed: "__libc_start_main (...libc...)" vs. "__libc_start_main (in /...libc...)". - One error is not reported: - Syscall param sigaction(act) points to unaddressable byte(s) - at 0x........: syscall (in /...libc...) - by 0x........: __libc_start_main (in /...libc...) - by 0x........: ... - Address 0x........ is not stack'd, malloc'd or (recently) free'd none/tests/faultstatus fails in tests 5 .. 9 because of "vex x86->IR: unhandled instruction bytes". Ditto for one/tests/x86/int, which also runs into a signal 4 (SIGILL) instead of signal 11 (SIGSEGV). none/tests/tls fails because of + Process terminating with default action of signal 11 (SIGSEGV) + GPF (Pointer out of bounds?) If you need more information or bug reports for any or these problems, please let me know. Regards, Jeroen. |
|
From: Julian S. <js...@ac...> - 2005-05-06 17:15:34
|
Jeroen Thanks for that. We are slowly working to make the regression test system more robust, so that it produces more repeatable results across a wider range of linux distros. And, of course, fix any genuine errors it throws up. On my SuSE 9.1 box I now get: == 172 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) (vex r1168, valgrind r3625) Could you send me the relevant .stderr.diff and .stdout.diff files for the failures you mention? Also, if you wanted to continue to track the failure rate, that would be very useful. Currently the nightly builds on my base machine "phoenix ( SuSE 9.1 )" are for 2.4.0; I will change this over to auto-build the 3 line instead. As the regtest system becomes more robust I would hope that results on all x86-linux distros converge. J > == 173 tests, 7 stderr failures, 1 stdout failure ================= > memcheck/tests/leak-tree (stderr) > memcheck/tests/writev (stderr) > memcheck/tests/x86/scalar (stderr) > corecheck/tests/fdleak_fcntl (stderr) > none/tests/faultstatus (stderr) > none/tests/tls (stdout) > none/tests/tls (stderr) > none/tests/x86/int (stderr) |
|
From: Nicholas N. <nj...@cs...> - 2005-05-06 20:42:56
|
On Thu, 5 May 2005, Jeroen N. Witmond wrote: > memcheck/tests/x86/scalar fails because > - line numbers do not match. I removed one line from the source (see > previous mails) but the line numbers are off by three. > - the format of some stack trace lines has changed: "__libc_start_main > (...libc...)" vs. "__libc_start_main (in /...libc...)". > - One error is not reported: > - Syscall param sigaction(act) points to unaddressable byte(s) > - at 0x........: syscall (in /...libc...) > - by 0x........: __libc_start_main (in /...libc...) > - by 0x........: ... > - Address 0x........ is not stack'd, malloc'd or (recently) free'd This one should be fixed now. N |
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-07 17:08:26
|
Nicholas wrote: > On Thu, 5 May 2005, Jeroen N. Witmond wrote: > >> memcheck/tests/x86/scalar fails because >> - line numbers do not match. I removed one line from the source (see >> previous mails) but the line numbers are off by three. >> - the format of some stack trace lines has changed: "__libc_start_main >> (...libc...)" vs. "__libc_start_main (in /...libc...)". >> - One error is not reported: >> - Syscall param sigaction(act) points to unaddressable byte(s) >> - at 0x........: syscall (in /...libc...) >> - by 0x........: __libc_start_main (in /...libc...) >> - by 0x........: ... >> - Address 0x........ is not stack'd, malloc'd or (recently) free'd > > This one should be fixed now. > You are right. It is fixed in both valgrind 2.4.0, and valgrind 3.0.0, where I first found it. (Nowadays, I should not use the name svn when I mean 3.0.0; it could cause confusion :-) Jeroen. |