This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC 0/4] Catch errors in get_prev_frame.


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
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]