This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [pushed][PATCH 6/7] Extended-remote fork catch
- From: Don Breazeal <donb at codesourcery dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>, "Breazeal, Don" <Don_Breazeal at mentor dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 28 May 2015 15:22:00 -0700
- Subject: Re: [pushed][PATCH 6/7] Extended-remote fork catch
- Authentication-results: sourceware.org; auth=none
- References: <1431451695-12273-1-git-send-email-donb at codesourcery dot com> <1431451695-12273-6-git-send-email-donb at codesourcery dot com> <87h9rehks0 dot fsf at redhat dot com> <55552F17 dot 3060807 at codesourcery dot com> <87y4kqg22f dot fsf at redhat dot com>
On 5/14/2015 4:40 PM, Sergio Durigan Junior wrote:
> 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,
>
Hi Sergio,
Just to close the loop on this: the new failures that you reported in
gdb.threads/fork-thread-pending.exp and gdb.base/foll-vfork.exp should
have now been addressed by the following three patches:
https://sourceware.org/ml/gdb-patches/2015-05/msg00696.html
https://sourceware.org/ml/gdb-patches/2015-05/msg00697.html
https://sourceware.org/ml/gdb-patches/2015-05/msg00698.html
Thanks
--Don