From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id ADCA43858402 for ; Tue, 28 Sep 2021 12:26:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ADCA43858402 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41744) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVCC4-0000TY-8p; Tue, 28 Sep 2021 08:26:44 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2318 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVCC3-0001dP-OP; Tue, 28 Sep 2021 08:26:44 -0400 Date: Tue, 28 Sep 2021 15:26:47 +0300 Message-Id: <83ee98khrs.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org In-Reply-To: <91f2597bd24d171c1337a4629f8237aa47c59082.1632828191.git.andrew.burgess@embecosm.com> (message from Andrew Burgess on Tue, 28 Sep 2021 12:26:24 +0100) Subject: Re: [PUSHED 6/6] gdb: print backtrace for internal error/warning References: <91f2597bd24d171c1337a4629f8237aa47c59082.1632828191.git.andrew.burgess@embecosm.com> X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2021 12:26:46 -0000 > From: Andrew Burgess > Date: Tue, 28 Sep 2021 12:26:24 +0100 > > ../../src.dev-3/gdb/maint.c:82: internal-error: blah > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Create a core file of GDB? (y or n) n > > My hope is that this backtrace might make it slightly easier to > diagnose GDB issues if all that is provided is the console output, I > find that we frequently get reports of an assert being hit that is > located in pretty generic code (frame.c, value.c, etc) and it is not > always obvious how we might have arrived at the assert. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26377 > --- > gdb/NEWS | 8 ++ > gdb/doc/gdb.texinfo | 13 ++ > .../gdb.base/bt-on-error-and-warning.exp | 118 ++++++++++++++++++ > gdb/testsuite/gdb.base/bt-on-fatal-signal.exp | 36 ------ > gdb/utils.c | 36 +++++- > 5 files changed, 174 insertions(+), 37 deletions(-) > create mode 100644 gdb/testsuite/gdb.base/bt-on-error-and-warning.exp > > diff --git a/gdb/NEWS b/gdb/NEWS > index d7c29c82edb..1e25cb8cc36 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -19,6 +19,14 @@ show source open > to open and read source code files, which can be useful if the files > are located over a slow network connection. > > +maint set internal-error backtrace on|off > +maint show internal-error backtrace > +maint set internal-warning backtrace on|off > +maint show internal-warning backtrace > + GDB can now print a backtrace of itself when it encounters either an > + internal-error, or an internal-warning. This is on by default for > + internal-error and off by default for internal-warning. Does this depend on libbacktrace? If so, should that be mentioned in the documentation? > +When @value{GDBN} reports an internal problem (error or warning) it is > +possible to have a backtrace of @value{GDBN} printed to stderr. This I suggest "standard error stream" instead of "stderr". The documentation parts are okay with these nits taken care of. Thanks.