gdb-7.11.1 - 2 weeks to go...

gdb-7.11.1 - 2 weeks to go...

[Joel Brobecker]

Hello everyone,

Just a quick update on this 7.11.1 release - our target release date
is about 2 weeks away. As far as I can tell from looking at...

    https://sourceware.org/gdb/wiki/GDB_7.11_Release

... we have 2 open PRs:

  * 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.

  * Bug 20039 - Using MI/all-stop, can't interrupt multi-threaded
    program after continue

    Looks like this one was already fixed in master as well.
    Should be a matter of backporting the relevant patches, if
    we can confirm they are safe.

So, all in all, we're looking good. If there are other blocking
issues for 7.11.1 that you know about but haven't been identified,
the best way forward is to:

  1. Create a PR
  2. Mention this PR here, so we can confirm with you whether
     the issue is, in fact, deemed blocking or not. If blocking,
     we'll update the PR's target milestone.

Thank you, all.
-- 
Joel

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

[Pedro Alves]

On 05/10/2016 05:17 PM, Joel Brobecker wrote:
> Hello everyone,
> 
> Just a quick update on this 7.11.1 release - our target release date
> is about 2 weeks away. As far as I can tell from looking at...
> 
>     https://sourceware.org/gdb/wiki/GDB_7.11_Release
> 
> ... we have 2 open PRs:
> 
>   * 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.

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

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

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.

Thanks,
Pedro Alves

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

[Joel Brobecker]

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

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

[Pedro Alves]

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

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

[Pedro Alves]

On 05/25/2016 04:22 PM, Pedro Alves wrote:
> I'll do that in a bit.

Now done:
 https://sourceware.org/ml/gdb-patches/2016-05/msg00450.html

Thanks,
Pedro Alves

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

[Joel Brobecker]

> On 05/25/2016 04:22 PM, Pedro Alves wrote:
> > I'll do that in a bit.
> 
> Now done:
>  https://sourceware.org/ml/gdb-patches/2016-05/msg00450.html

Thanks, Pedro!

-- 
Joel