This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: gdb-7.11.1 - 2 weeks to go...
- From: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 25 May 2016 16:22:37 +0100
- Subject: Re: gdb-7.11.1 - 2 weeks to go...
- Authentication-results: sourceware.org; auth=none
- References: <20160510161756 dot GB26324 at adacore dot com> <395c33b0-7071-ed80-915a-dd8dbefe2786 at redhat dot com> <20160520132452 dot GF26324 at adacore dot com>
On 05/20/2016 02:24 PM, Joel Brobecker wrote:
> Hi Pedro,
>
>> Odd, it definitely doesn't work for me on master.
>
> I don't recall exactly, but I must have thought it was fixed just
> because I saw a commit. Sorry if that caused some confusion.
No worries, no real confusion.
>> Another option that just occurred to me, is to apply the fuller fix
>> to the branch (patch #6 in the series), and disable the
>> attach-many-short-lived-threads.exp test in the branch? GDB regresses
>> in the use case of attaching to a program that is constantly spawning
>> many threads in quick succession, though that's a contrived use case
>> to expose problems. Probably no program in the wild is like that.
>> I hope. Use cases like Go programs with tons of goroutines make me
>> worry a bit.
>
> At this stage, I think we should only commit changes we are confident
> about. If that leaves things broken and regressing, well, better
> document them, especially if we have workarounds, or else direct
> people to 7.10 or future releases.
*nod*
>
> In this case, if you feel good about your simpler fix, we could go
> with that on the branch, while we aim at getting your complete
> series on master. Just thinking out loud.
> Another option is doing nothing,
To be clear, the reported bug is unrelated to
attach-many-short-lived-threads.exp. It's just that fixing the bug
surprisingly regresses attach-many-short-lived-threads.exp.
> or disabling attach-many-short-lived-threads.exp. This
> test is very good, but also not always representative of typical
> programs.
>
Right.
The full fix is in master since yesterday. I let the buildbot chew
on it overnight, and looked at fail reports. Although some builders
showed attach-many-short-lived-threads.exp failures, all I saw
looked like pre-existing racy fails that also appear before the fixes.
I've spent today trying to come up with a simpler fix, but all I tried
has some significant drawback. E.g., I tried making the detach path
cope with an lwp not in gdb's thread list (avoiding the
PR gdb/19828 assertion), but then gdb crashes elsewhere. Disabling
all-stop-on-top-of-non-stop would be another potential path forward, but
although it'd be a one-liner, it's quite an invasive change to make
in a patch release, as it completely changes how the infrun.c ->
linux-nat.c cooperate...
So all in all, I prefer the approach of pushing the fuller fix to the
branch, without the invasive optimization bits, and disable the
attach-many-short-lived-threads.exp test.
I'll do that in a bit.
Thanks,
Pedro Alves