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]

[RFC 0/4] Catch errors in get_prev_frame.


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]