This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
make installcheck results
- From: Mark Wielaard <mjw at redhat dot com>
- To: systemtap at sources dot redhat dot com
- Date: Wed, 22 Oct 2008 14:56:06 +0200
- Subject: make installcheck results
Hi,
I have been working on getting the number of known failures in the make
installcheck as close to zero as possible. We are almost there for at
least one architecture, 2.6.18/86_64/el5 kernel, but others are still
some way off. Here is an overview of the machines I tested on. The only
downside of doing a full make installcheck is that it takes about an
hour on some machines. But it often catches regressions. So I would
encourage people to run it occasionally when adding patches.
All results were against git master of this morning (commit dd09ee8f)
with elfutils 0.137 + two patches (see bug #6928).
- 2.6.18-92.1.13.el5 x86_64
# of expected passes 621
# of unexpected failures 4
# of unexpected successes 8
# of expected failures 200
# of unknown successes 2
# of known failures 5
# of untested testcases 24
# of unsupported tests 3
FAIL: systemtap.base/stmt_rel.stp
FAIL: buildok/twentyfive.stp
FAIL: buildok/vfs-all-probes.stp
FAIL: buildok/vfs_testcase.stp
stmt_rel.stp seems to be either an optimisation or missing debug line
info in the function being tested (the tests expects to hit 4 different
lines, but only hits 3).
twentyfive.stp seems to be an elfutils regression. Tracked in bug #6950.
Needs a simpler reproducer.
The vfs tests have a pending patch in bug #6972.
- 2.6.18-92.1.13.el5
# of expected passes 583
# of unexpected failures 14
# of unexpected successes 8
# of expected failures 200
# of unknown successes 2
# of known failures 5
# of untested testcases 24
# of unsupported tests 1
FAIL: bad kprobe registration (eof)
FAIL: systemtap.base/global_init.stp shutdown (eof)
FAIL: systemtap.base/if.stp shutdown (eof)
FAIL: systemtap.base/inc.stp shutdown (eof)
FAIL: systemtap.base/not.stp shutdown (eof)
FAIL: systemtap.base/print.stp shutdown (eof)
FAIL: systemtap.base/stmt_rel.stp
FAIL: systemtap.base/tri.stp shutdown (eof)
FAIL: buildok/twentyfive.stp
FAIL: buildok/vfs-all-probes.stp
FAIL: buildok/vfs_testcase.stp
FAIL: gtod (228)
FAIL: 32-bit futimes
FAIL: 32-bit stat
The (oef) test failures might be test harness glitches.
gtod needs investigation.
The 32-bit futimes and stat produce the wrong time because the argument
is shorter than expected (64-bit).
Rest same as above.
- 2.6.26.5-45.fc9.x86_64
# of expected passes 632
# of unexpected failures 14
# of unexpected successes 8
# of expected failures 200
# of known failures 7
# of untested testcases 4
# of unsupported tests 2
FAIL: bz6850 -p4
FAIL: bz6850 -p5
FAIL: systemtap.base/stmt_rel.stp
FAIL: uprobes -p4
FAIL: uprobes -p5 (0)
FAIL: systemtap.examples/process/sig_by_pid build
FAIL: systemtap.examples/process/sig_by_pid run
FAIL: systemtap.examples/process/sig_by_proc build
FAIL: systemtap.examples/process/sig_by_proc run
FAIL: systemtap.examples/process/sigkill build
FAIL: systemtap.examples/process/sigkill run
FAIL: systemtap.examples/process/sigmon build
FAIL: systemtap.examples/process/sigmon run
FAIL: buildok/signal-all-probes.stp
This kernel doesn't support uprobes yet, causing the bz6850 and uprobes
failures.
All the signal related failures seem to come down to a gcc inline
optimization described in bug #1155
Rest as above.
- 2.6.26.5-28.fc8 i386
# of expected passes 581
# of unexpected failures 17
# of unexpected successes 8
# of expected failures 200
# of unknown successes 1
# of known failures 6
# of untested testcases 24
FAIL: bad kprobe registration (eof)
FAIL: bz6850 -p4
FAIL: bz6850 -p5
FAIL: systemtap.base/stmt_rel.stp
FAIL: uprobes -p4
FAIL: uprobes -p5 (0)
FAIL: backtrace of yyy_func2 (2)
FAIL: print_stack of yyy_func2 (2)
FAIL: backtrace of yyy_func3 (2)
FAIL: print_stack of yyy_func3 (2)
FAIL: backtrace of yyy_func4 (2)
FAIL: print_stack of yyy_func4 (2)
FAIL: buildok/twentyfive.stp
FAIL: semok/twenty.stp
FAIL: systemtap.printf/memory1.stp
FAIL: 32-bit futimes
FAIL: 32-bit stat
The el5 kernels don't have CONFIG_FRAME_POINTER defined, the fedora
kernels do have it defined for x86. Which seem to cause the backtrace
mismatches. I'll investigate whether my unwind based backtrace work can
give better results here.
The twenty.stp and memory1.stp need investigation.
Rest as above.