From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1452 invoked by alias); 20 May 2016 13:25:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 1437 invoked by uid 89); 20 May 2016 13:25:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=loud, representative X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 20 May 2016 13:24:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4419E116B97; Fri, 20 May 2016 09:24:54 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XbmCqDVT7NAq; Fri, 20 May 2016 09:24:54 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 1CB551169C4; Fri, 20 May 2016 09:24:54 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 46259428E0; Fri, 20 May 2016 06:24:52 -0700 (PDT) Date: Fri, 20 May 2016 13:25:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: gdb-7.11.1 - 2 weeks to go... Message-ID: <20160520132452.GF26324@adacore.com> References: <20160510161756.GB26324@adacore.com> <395c33b0-7071-ed80-915a-dd8dbefe2786@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <395c33b0-7071-ed80-915a-dd8dbefe2786@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-05/txt/msg00355.txt.bz2 Hi Pedro, > > * Bug 19828 - 7.11 regression: non-stop gdb -p > 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 : 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