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

[Joel Brobecker <brobecker@adacore.com>]

Hi Pedro,

> >   * Bug 19828 - 7.11 regression: non-stop gdb -p <process from a
> >     container>: internal error
> > 
> >     Looks already fixed on master, so there is a chance we might
> >     be able to fix that on the branch soon.
> > 
> 
> 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.

> This is the one that I said in the other status thread that I had
> a patch for, but that it surprisingly caused regressions in
> the attach-many-short-lived-threads.exp testcase.
> 
> I finally managed to find some time to stare at "set debug infrun"
> logs, and wrote (I think) a full fix, here:
> 
>  [PATCH 0/6] Fix PR gdb/19828 (attach -> internal error) and attach optimizations
>  https://sourceware.org/ml/gdb-patches/2016-05/msg00335.html

Small correction:
https://www.sourceware.org/ml/gdb-patches/2016-05/msg00328.html

> That's a bit ... invasive ...

a bit... :-)

> I have a simpler version too, which is being carried by Fedora for
> a few weeks without reports of problems:
> 
>  [PATCH/7.11.1?] Simpler fix PR gdb/19828: gdb -p <process from a container>: internal error
>  https://sourceware.org/ml/gdb-patches/2016-05/msg00335.html
> 
> ... though that's not as comprehensive as the bigger series.
> It leaves "attach&" (background attach) broken...  I haven't heard
> complaints about that so far; maybe nobody uses that command...
> 
> 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.

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, or disabling attach-many-short-lived-threads.exp. This
test is very good, but also not always representative of typical
programs.

-- 
Joel