This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/14971] Failures in gdb.base/longjmp.exp
- From: "tromey at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 17 Jan 2013 19:17:18 +0000
- Subject: [Bug gdb/14971] Failures in gdb.base/longjmp.exp
- Auto-submitted: auto-generated
- References: <bug-14971-4717@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14971
--- Comment #10 from Tom Tromey <tromey at redhat dot com> 2013-01-17 19:17:18 UTC ---
(In reply to comment #9)
> I'm now trying to upstream the appropriate changes (things like the patches
> I've already sent to gdb and gcc) and get to the point where I can run a
> buildbot using GDB ToT and Clang ToT. I'll only be able to do this if I can get
> stable red/green results - a few spurious failures are going to block that
> effort. So, one way or another, I will be trying to find a way to resolve these
> failures. While upgrading glibc on my build slaves may be one solution, I was
> hoping for a solution that would scale better to other machines/users (so that
> developers of GDB or Clang attempting to reproduce failures or just running the
> suite on a new change to avoid committing regressions wouldn't see spurious
> extra failures that could lead them down the wrong path)
I think you need to establish a baseline of failing tests and go from there.
Some tests are racy. On my machine I see a handful of tests that always
fail (many not applicable in the clang case: ada, fortran, ...).
I believe Jan disables some tests on his own tester due to flakiness.
For this particular test maybe you can find a way to see whether the
test is run against glibc without probes and kfail it there.
It seems tricky though.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.