This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 0/4] Catch errors in get_prev_frame.
- From: Andrew Burgess <aburgess at broadcom dot com>
- To: <gdb-patches at sourceware dot org>
- Date: Tue, 15 Apr 2014 10:11:21 +0100
- Subject: Re: [RFC 0/4] Catch errors in get_prev_frame.
- Authentication-results: sourceware.org; auth=none
- References: <533EC5B7 dot 6080600 at broadcom dot 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
>
>