gdb-7.11.1 - 2 weeks to go...
Pedro Alves
palves@redhat.com
Wed May 25 15:22:00 GMT 2016
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
More information about the Gdb-patches
mailing list