This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/14971] Failures in gdb.base/longjmp.exp


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]