From: Andrew Burgess <aburgess@broadcom.com>
To: <gdb-patches@sourceware.org>
Subject: Re: [RFC 0/4] Catch errors in get_prev_frame.
Date: Tue, 15 Apr 2014 09:11:00 -0000 [thread overview]
Message-ID: <534CF7B9.6070709@broadcom.com> (raw)
In-Reply-To: <533EC5B7.6080600@broadcom.com>
Ping.
On 04/04/2014 3:46 PM, Andrew Burgess wrote:
> While working on a reproducer for this patch:
> https://sourceware.org/ml/gdb-patches/2014-03/msg00629.html
>
> I ran into a few other issues. The route cause of the problems I'm
> seeing is that not all errors thrown within get_prev_frame are caught.
> This causes a couple of problems,
>
> 1. For the MI this means that commands like -stack-info-depth will
> return an error rather than a result. Even more annoying, is that
> depending on where in the process the error is thrown enough state may
> be left set that the /next/ time -stack-info-depth is asked, the correct
> result is given!
>
> 2. For standard CLI backtraces our the results are (I think)
> inconsistent, so for example some backtraces will end with a message
> like: "Backtrace stopped: previous frame inner to this frame (corrupted
> stack?)", this message will be displayed every time the backtrace is
> requested, in other cases though, the reason is only displayed the first
> time a backtrace is requested, this is the case when an uncaught error
> causes the backtrace to stop, also in the uncaught error case the
> "Backtrace stopped" prefix does not appear.
>
> This patch set tries to fix both these issues by holding a frame
> specific string that describes why the backtrace stopped at this frame
> (only for the last frame in the backtrace obviously). If this string is
> not set then we still use the existing generic strings.
>
> A new TRY_CATCH inside get_prev_frame catches (currently) all unhandled
> errors, the error message from these errors is then used as a frame
> specific stop reason string. There's a new unwind_stop_reason code for
> this case, UNWIND_MISC_ERROR.
>
> If it's felt that catching all errors like this is too much then I could
> soften this to just catching MEMORY_ERRORs, as right now the problems
> I'm seeing all relate to accessing memory through a corrupted stack pointer.
>
> Here's what each patch does:
>
> #1 - This patch just adds some tests, some of the tests fail, and are
> fixed by later patches in this series.
>
> #2 - An error in the wrong place leaves a frame partially initialised,
> this can then cause internal errors / assertions to fire. Add a clean
> up to fix this issue.
>
> #3 Deprecate frame_stop_reason_string, rename all use sites. I'm going
> to add a new version in the next patch that takes a struct frame_info
> pointer.
>
> #4 Add the new TRY_CATCH and the new stop reason string into the
> frame_info structure.
>
> Thanks,
> Andrew
>
>
next prev parent reply other threads:[~2014-04-15 9:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-04 14:46 Andrew Burgess
2014-04-04 14:47 ` [RFC 1/4] New tests for backtracing with a corrupted stack Andrew Burgess
2014-04-04 14:48 ` [RFC 2/4] Remove previous frame if we error during compute_frame_id Andrew Burgess
2014-04-04 14:53 ` Andrew Burgess
2014-04-15 19:02 ` Pedro Alves
2014-04-04 14:49 ` [RFC 3/4] Deprecate frame_stop_reason_string Andrew Burgess
2014-04-04 14:55 ` Andrew Burgess
2014-04-04 14:50 ` [RFC 4/4] Add TRY_CATCH to get_prev_frame and frame specific strop strings Andrew Burgess
2014-04-15 9:11 ` Andrew Burgess [this message]
2014-04-17 10:15 ` [PATCH v2 4/4] Add a TRY_CATCH to get_prev_frame to better handle errors during unwind Andrew Burgess
2014-04-17 10:15 ` [PATCH v2 2/4] Remove previous frame if an error occurs when computing frame id " Andrew Burgess
2014-04-17 10:15 ` [PATCH v2 0/4] Catch errors in get_prev_frame Andrew Burgess
2014-04-17 10:15 ` [PATCH v2 3/4] Deprecate frame_stop_reason_string Andrew Burgess
2014-04-29 19:56 ` Pedro Alves
2014-04-30 10:46 ` Andrew Burgess
2014-04-17 10:15 ` [PATCH v2 1/4] New test for backtrace when the stack pointer is invalid (inaccessible) Andrew Burgess
2014-04-30 10:55 ` [PATCH v3 0/4] Catch errors in get_prev_frame Andrew Burgess
2014-04-30 10:55 ` [PATCH v3 3/4] Deprecate frame_stop_reason_string Andrew Burgess
2014-05-28 17:26 ` Pedro Alves
2014-05-28 23:26 ` Andrew Burgess
2014-05-29 9:00 ` Pedro Alves
2014-05-29 9:53 ` Andrew Burgess
2014-05-29 9:56 ` Pedro Alves
2014-04-30 10:55 ` [PATCH v3 2/4] Remove previous frame if an error occurs when computing frame id during unwind Andrew Burgess
2014-05-16 15:37 ` Pedro Alves
2014-05-28 23:16 ` Andrew Burgess
2014-04-30 10:55 ` [PATCH v3 1/4] New test for backtrace when the stack pointer is invalid (inaccessible) Andrew Burgess
2014-05-28 18:42 ` Pedro Alves
2014-04-30 10:55 ` [PATCH v3 4/4] Add a TRY_CATCH to get_prev_frame to better handle errors during unwind Andrew Burgess
2014-05-28 18:31 ` Pedro Alves
2014-05-28 23:35 ` Andrew Burgess
2014-05-29 9:41 ` Pedro Alves
2014-05-29 23:02 ` Andrew Burgess
2014-05-30 11:46 ` Pedro Alves
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=534CF7B9.6070709@broadcom.com \
--to=aburgess@broadcom.com \
--cc=gdb-patches@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: link
Be 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