public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug backtrace/15558] New: "set backtrace limit" can cause assertion failure
@ 2013-05-31 18:42 tromey at redhat dot com
2013-06-06 19:35 ` [Bug backtrace/15558] " tromey at redhat dot com
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: tromey at redhat dot com @ 2013-05-31 18:42 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=15558
Bug ID: 15558
Summary: "set backtrace limit" can cause assertion failure
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: backtrace
Assignee: unassigned at sourceware dot org
Reporter: tromey at redhat dot com
"set backtrace limit" can cause an assertion failure.
If the limit is reached at an inline frame, then this
assertion in inline_frame_this_id will fail:
gdb_assert (frame_id_p (*this_id));
One simple workaround is to change get_prev_frame to ignore the
backtrace limit for INLINE_FRAME. This isn't completely ideal,
though.
Pedro suggests that most internals code should use get_prev_frame_1
instead, and bypass all the checks that correspond to user settings.
E.g., gcore.c or infrun.c:stepped_in_from. The idea would be to
use get_prev_frame only in cases like "bt" or the MI equivalent.
Another wrinkle is that the Python code should probably use
the _1 variant -- but then this will mean that "backtrace limit"
won't be in effect when a Python frame filter is found. So, some
extra code will be needed here.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug backtrace/15558] "set backtrace limit" can cause assertion failure
2013-05-31 18:42 [Bug backtrace/15558] New: "set backtrace limit" can cause assertion failure tromey at redhat dot com
@ 2013-06-06 19:35 ` tromey at redhat dot com
2014-04-18 9:42 ` cvs-commit at gcc dot gnu.org
2014-04-18 9:45 ` palves at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: tromey at redhat dot com @ 2013-06-06 19:35 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=15558
Tom Tromey <tromey at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at sourceware dot org |tromey at redhat dot com
--- Comment #1 from Tom Tromey <tromey at redhat dot com> ---
Testing a patch.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug backtrace/15558] "set backtrace limit" can cause assertion failure
2013-05-31 18:42 [Bug backtrace/15558] New: "set backtrace limit" can cause assertion failure tromey at redhat dot com
2013-06-06 19:35 ` [Bug backtrace/15558] " tromey at redhat dot com
@ 2014-04-18 9:42 ` cvs-commit at gcc dot gnu.org
2014-04-18 9:45 ` palves at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-04-18 9:42 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=15558
--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".
The branch, master has been updated
via 51d481464ec03be1f5479ed648cc38fb944d7fc0 (commit)
from 1bdad2e0421a56e16c0f4623e6320e1225cbe5ee (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=51d481464ec03be1f5479ed648cc38fb944d7fc0
commit 51d481464ec03be1f5479ed648cc38fb944d7fc0
Author: Pedro Alves <palves@redhat.com>
Date: Fri Apr 18 10:15:21 2014 +0100
Fix PR backtrace/15558
This PR is about an assertion failure in GDB that can be triggered by
setting "backtrace limit" to a value that causes GDB to stop unwinding
after an inline frame. In this case, an assertion in
inline_frame_this_id will trigger:
/* We need a valid frame ID, so we need to be based on a valid
frame. (...). */
gdb_assert (frame_id_p (*this_id));
Looking at the function:
static void
inline_frame_this_id (struct frame_info *this_frame,
void **this_cache,
struct frame_id *this_id)
{
struct symbol *func;
/* In order to have a stable frame ID for a given inline function,
we must get the stack / special addresses from the underlying
real frame's this_id method. So we must call get_prev_frame.
Because we are inlined into some function, there must be previous
frames, so this is safe - as long as we're careful not to
create any cycles. */
*this_id = get_frame_id (get_prev_frame (this_frame));
we see we're computing the frame id for the inline frame. If this is
an inline frame, which is a virtual frame constructed based on debug
info, on top of a real stack frame, we should _always_ be able to find
where the frame was inlined into, as that ultimately just means
peeling off the virtual frames on top of the real stack frame. If
there ultimately was no prev (real) stack frame, then we wouldn't have
been able to construct the inline frame either, by design. That's
what the assertion catches.
So we have an inline frame, we should _always_ be able to compute its
ID, even if that means bypassing the user backtrace limits to get at
the real stack frame's info. The problem is that inline_frame_id
calls get_prev_frame, and that takes user backtrace limits into
account. Code that wants to bypass the limits calls get_prev_frame_1
instead.
Note how get_prev_frame_1 already skips all checks for inline frames:
/* If we are unwinding from an inline frame, all of the below tests
were already performed when we unwound from the next non-inline
frame. We must skip them, since we can not get THIS_FRAME's ID
until we have unwound all the way down to the previous non-inline
frame. */
if (get_frame_type (this_frame) == INLINE_FRAME)
return get_prev_frame_if_no_cycle (this_frame);
And note how the related frame_unwind_caller_id function also uses
get_prev_frame_1:
struct frame_id
frame_unwind_caller_id (struct frame_info *next_frame)
{
struct frame_info *this_frame;
/* Use get_prev_frame_1, and not get_prev_frame. The latter will
truncate
the frame chain, leading to this function unintentionally
returning a null_frame_id (e.g., when a caller requests the frame
ID of "main()"s caller. */
next_frame = skip_artificial_frames (next_frame);
this_frame = get_prev_frame_1 (next_frame);
if (this_frame)
return get_frame_id (skip_artificial_frames (this_frame));
else
return null_frame_id;
}
get_prev_frame_1 is currently static in frame.c. As a _1 suffix is
not a good name for an extern function, I've renamed it.
Tested on x86-64 Fedora 17.
gdb/
2014-04-18 Pedro alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
PR backtrace/15558
* frame.c (get_prev_frame_1): Rename to ...
(get_prev_frame_always): ... this, and make extern. Adjust.
(skip_artificial_frames): Use get_prev_frame_always.
(frame_unwind_caller_id, frame_pop, get_prev_frame)
(get_frame_unwind_stop_reason): Adjust to rename.
* frame.h (get_prev_frame_always): Declare.
* inline-frame.c: Include frame.h.
(inline_frame_this_id): Use get_prev_frame_always.
gdb/testsuite/
2014-04-18 Tom Tromey <palves@redhat.com>
Pedro alves <tromey@redhat.com>
PR backtrace/15558
* gdb.opt/inline-bt.exp: Test backtracing from an inline function
with a backtrace limit.
* gdb.python/py-frame-inline.exp: Test running to an inline
function with a backtrace limit, and printing the newest frame.
* gdb.python/py-frame-inline.c (main): Call f.
-----------------------------------------------------------------------
Summary of changes:
gdb/ChangeLog | 13 +++++++++++
gdb/frame.c | 31 +++++++++++++++-----------
gdb/frame.h | 7 ++++++
gdb/inline-frame.c | 11 +++++----
gdb/testsuite/ChangeLog | 10 ++++++++
gdb/testsuite/gdb.opt/inline-bt.exp | 16 +++++++++++++
gdb/testsuite/gdb.python/py-frame-inline.c | 4 ++-
gdb/testsuite/gdb.python/py-frame-inline.exp | 14 +++++++++++
8 files changed, 87 insertions(+), 19 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug backtrace/15558] "set backtrace limit" can cause assertion failure
2013-05-31 18:42 [Bug backtrace/15558] New: "set backtrace limit" can cause assertion failure tromey at redhat dot com
2013-06-06 19:35 ` [Bug backtrace/15558] " tromey at redhat dot com
2014-04-18 9:42 ` cvs-commit at gcc dot gnu.org
@ 2014-04-18 9:45 ` palves at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: palves at redhat dot com @ 2014-04-18 9:45 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=15558
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |palves at redhat dot com
Resolution|--- |FIXED
Target Milestone|--- |7.8
--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
Fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-04-18 9:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-31 18:42 [Bug backtrace/15558] New: "set backtrace limit" can cause assertion failure tromey at redhat dot com
2013-06-06 19:35 ` [Bug backtrace/15558] " tromey at redhat dot com
2014-04-18 9:42 ` cvs-commit at gcc dot gnu.org
2014-04-18 9:45 ` palves at redhat dot com
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).