Re: gdb-7.11.1 - 2 weeks to go...

[Pedro Alves <palves@redhat.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