* gdb-7.11.1 - 2 weeks to go...
@ 2016-05-10 16:18 Joel Brobecker
2016-05-19 15:21 ` Pedro Alves
0 siblings, 1 reply; 6+ messages in thread
From: Joel Brobecker @ 2016-05-10 16:18 UTC (permalink / raw)
To: gdb-patches
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: gdb-7.11.1 - 2 weeks to go... 2016-05-10 16:18 gdb-7.11.1 - 2 weeks to go Joel Brobecker @ 2016-05-19 15:21 ` Pedro Alves 2016-05-20 13:25 ` Joel Brobecker 0 siblings, 1 reply; 6+ messages in thread From: Pedro Alves @ 2016-05-19 15:21 UTC (permalink / raw) To: Joel Brobecker, gdb-patches 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb-7.11.1 - 2 weeks to go... 2016-05-19 15:21 ` Pedro Alves @ 2016-05-20 13:25 ` Joel Brobecker 2016-05-25 15:22 ` Pedro Alves 0 siblings, 1 reply; 6+ messages in thread From: Joel Brobecker @ 2016-05-20 13:25 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb-patches 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb-7.11.1 - 2 weeks to go... 2016-05-20 13:25 ` Joel Brobecker @ 2016-05-25 15:22 ` Pedro Alves 2016-05-25 17:45 ` Pedro Alves 0 siblings, 1 reply; 6+ messages in thread From: Pedro Alves @ 2016-05-25 15:22 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb-7.11.1 - 2 weeks to go... 2016-05-25 15:22 ` Pedro Alves @ 2016-05-25 17:45 ` Pedro Alves 2016-05-27 14:05 ` Joel Brobecker 0 siblings, 1 reply; 6+ messages in thread From: Pedro Alves @ 2016-05-25 17:45 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb-7.11.1 - 2 weeks to go... 2016-05-25 17:45 ` Pedro Alves @ 2016-05-27 14:05 ` Joel Brobecker 0 siblings, 0 replies; 6+ messages in thread From: Joel Brobecker @ 2016-05-27 14:05 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb-patches > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-05-27 14:05 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-10 16:18 gdb-7.11.1 - 2 weeks to go Joel Brobecker 2016-05-19 15:21 ` Pedro Alves 2016-05-20 13:25 ` Joel Brobecker 2016-05-25 15:22 ` Pedro Alves 2016-05-25 17:45 ` Pedro Alves 2016-05-27 14:05 ` Joel Brobecker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).