This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Test suite docs
> Date: Sat, 13 Jan 2007 17:07:42 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> FWIW, I present below the failures and unexpected successes on the
> system where I ran the test suite (an x86_64 Ubuntu box). With the
> exception of Ada/gnatmake related failures, they all seem to be real
> problems. In particular, maint.exp, corefile.exp, sigaltstack.exp,
> sigbpt.exp, sigstep.exp, and staticthreads/watchthreads look
> disturbing. Does anyone else get them on a GNU/Linux system?
>
> FAIL: gdb.base/corefile.exp: accessing mmapped data in core file (mapping address not found in core file)
I don't think I've ever seen this one myself. The problem could be
that your ulimit is set such that your system creates truncated core
files.
> FAIL: gdb.base/maint.exp: maint info sections .text
Never seen this one.
> FAIL: gdb.base/sigaltstack.exp: finish from catch LEAF (the program exited)
> FAIL: gdb.base/sigaltstack.exp: finish to throw INNER
> FAIL: gdb.base/sigaltstack.exp: finish to catch INNER
> FAIL: gdb.base/sigaltstack.exp: finish from catch INNER
> FAIL: gdb.base/sigaltstack.exp: finish to OUTER
> FAIL: gdb.base/sigaltstack.exp: finish to catch MAIN
> FAIL: gdb.base/sigaltstack.exp: finish to MAIN
> FAIL: gdb.base/sigbpt.exp: stepi; stepi out of handler
> FAIL: gdb.base/sigbpt.exp: stepi bp before segv; stepi out of handler
> FAIL: gdb.base/sigbpt.exp: stepi bp at segv; stepi out of handler
> FAIL: gdb.base/sigbpt.exp: stepi bp before and at segv; stepi out of handler
> FAIL: gdb.base/siginfo.exp: step out of handler
> KFAIL: gdb.base/signals.exp: override SIGINT (PRMS: gdb/1707)
> FAIL: gdb.base/sigstep.exp: step from handler; leave handler
> FAIL: gdb.base/sigstep.exp: stepi from handleri; leave handler
> FAIL: gdb.base/sigstep.exp: stepi from handleri; leave signal trampoline
> FAIL: gdb.base/sigstep.exp: next from handler; leave handler
> ...
These are fairly common. I think we know how to fix them properly,
although this might only work for some Linux systems.
> UNSUPPORTED: gdb.objc/basicclass.exp: Couldn't compile ../.././gdb/testsuite/gdb.objc/basicclass.m: unrecognized error
> UNSUPPORTED: gdb.objc/nondebug.exp: Couldn't compile ../.././gdb/testsuite/gdb.objc/nondebug.m: unrecognized error
> UNSUPPORTED: gdb.objc/objcdecode.exp: Couldn't compile ../.././gdb/testsuite/gdb.objc/objcdecode.m: unrecognized error
Could be that the Objective C compiler isn't installed on your system.
If that's the cause of the problem, we should improve the tests such
that they print something more obvious.
> FAIL: gdb.threads/staticthreads.exp: running to main in runto
> FAIL: gdb.threads/staticthreads.exp: Continue to main's call of sem_post
> FAIL: gdb.threads/staticthreads.exp: handle SIG32 helps
> KFAIL: gdb.threads/tls.exp: info address me (PRMS: gdb/1294)
> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
> FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[1] hit
> FAIL: gdb.threads/watchthreads.exp: watchpoint on args[0] hit in thread
> FAIL: gdb.threads/watchthreads.exp: watchpoint on args[1] hit in thread
> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
The threads stuff only works if you have the right combination of
kernel and glibc. I'm not aware of any "official" Linux distribution
that gets all the bits right.
This is what makes it so difficult to get the testsuite FAIL-free.
The sheer number of Linux distributions out there that all appear as
i386-unknown-linux-gnu to us, makes it very hard to selectively XFAIL
tests. On systems with a more formal release engineering procedure,
this would be much easier since for example m88k-unknown-openbsd3.9
refers to a single official release, and if I know somethings is
broken there but fixed in m88k-unknown-openbsd4.0 I can put the proper
setup_xfail in the test.
That said, even on OpenBSD I have been pretty lazy with putting in the
proper setup_xfails. Not many people besides me actually build the
FSF release of gdb on OpenBSD, since I make sure the gdb shipped with
OpenBSD releases is fairly up to date and works well.
Mark