public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug gdb/26377] generate backtrace upon assert Date: Tue, 28 Sep 2021 11:27:36 +0000 [thread overview] Message-ID: <bug-26377-4717-2SGsrjbqIb@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-26377-4717@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=26377 --- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=91f2597bd24d171c1337a4629f8237aa47c59082 commit 91f2597bd24d171c1337a4629f8237aa47c59082 Author: Andrew Burgess <andrew.burgess@embecosm.com> Date: Thu Aug 12 18:24:59 2021 +0100 gdb: print backtrace for internal error/warning This commit builds on previous work to allow GDB to print a backtrace of itself when GDB encounters an internal-error or internal-warning. This fixes PR gdb/26377. There's not many places where we call internal_warning, and I guess in most cases the user would probably continue their debug session. And so, in order to avoid cluttering up the output, by default, printing of a backtrace is off for internal-warnings. In contrast, printing of a backtrace is on by default for internal-errors, as I figure that in most cases hitting an internal-error is going to be the end of the debug session. Whether a backtrace is printed or not can be controlled with the new settings: maintenance set internal-error backtrace on|off maintenance show internal-error backtrace maintenance set internal-warning backtrace on|off maintenance show internal-warning backtrace Here is an example of what an internal-error now looks like with the backtrace included: (gdb) maintenance internal-error blah ../../src.dev-3/gdb/maint.c:82: internal-error: blah A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x5c61ca gdb_internal_backtrace_1 ../../src.dev-3/gdb/bt-utils.c:123 0x5c626d _Z22gdb_internal_backtracev ../../src.dev-3/gdb/bt-utils.c:165 0xe33237 internal_vproblem ../../src.dev-3/gdb/utils.c:393 0xe33539 _Z15internal_verrorPKciS0_P13__va_list_tag ../../src.dev-3/gdb/utils.c:470 0x1549652 _Z14internal_errorPKciS0_z ../../src.dev-3/gdbsupport/errors.cc:55 0x9c7982 maintenance_internal_error ../../src.dev-3/gdb/maint.c:82 0x636f57 do_simple_func ../../src.dev-3/gdb/cli/cli-decode.c:97 .... snip, lots more backtrace lines .... --------------------- ../../src.dev-3/gdb/maint.c:82: internal-error: blah A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. ../../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 -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2021-09-28 11:27 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-12 14:33 [Bug gdb/26377] New: " vries at gcc dot gnu.org 2020-08-12 20:47 ` [Bug gdb/26377] " tromey at sourceware dot org 2020-08-13 12:48 ` vries at gcc dot gnu.org 2020-11-29 9:25 ` vries at gcc dot gnu.org 2021-08-30 14:17 ` vries at gcc dot gnu.org 2021-09-28 11:27 ` cvs-commit at gcc dot gnu.org [this message] 2021-09-28 15:22 ` vries at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-26377-4717-2SGsrjbqIb@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).