Re: [pushed][PATCH 6/7] Extended-remote fork catch

[Sergio Durigan Junior <sergiodj@redhat.com>]

On Thursday, May 14 2015, Don Breazeal wrote:

> The failures in gdb.base/foll-vfork.exp, gdb.base/multi-forks.exp, and
> gdb.threads/fork-thread-pending.exp are not expected.

Hey Dan,

Well, because the GDB testsuite still has tests that fail intermitently,
I was mostly talking about the failures on
gdb.threads/fork-thread-pending.exp and gdb.base/foll-vfork.exp.

> The failures in gdb.threads/interrupted-hand-call.exp and
> gdb.gdb/python-selftest.exp are failures that I saw intermittently in my
> testing, and was able to reproduce on the mainline, as discussed here:
> https://sourceware.org/ml/gdb-patches/2015-05/msg00180.html

Yeah, as Pedro already explained in this message, our testsuite is not
entirely clean.  But a "New FAIL", in general, means that a regression
has been introduced.

> The failure in gdb.base/attach.exp I don't know...the log doesn't
> provide any clues.  I'll have to reproduce it to understand it.

Oh, this one is racy.  But if you're interested in following this up,
you can get the logs here:

  <http://gdb-build.sergiodj.net/cgit>

You have to choose the repository with the same name as the builder you
saw the failure, and then, inside it, you can look for a git tag
containing the commit hash (from the upstream GDB repo) that triggered
the failure.  Or, if you have the message from gdb-testers, you can see
the direct link to the logs in the "Testsuite log (gdb.sum and gdb.log)
URL(s):" field.

> Disappointing.  I'll check out a clean sandbox and see if I can
> reproduce any of these results.

Thanks for looking into this.  As I said, I think the priority should be
the new failures on gdb.threads/fork-thread-pending.exp and
gdb.base/foll-vfork.exp.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/