Re: [RFA]: issue warnings for frame offenses

[Jeff Johnston <jjohnstn at redhat dot com>]

Andrew Cagney wrote:
> Joel Brobecker wrote:
>
> > > The attached patch changes a few backtrace termination scenarios in 
> > > frame.c to issue a warning and terminate the backtrace rather than 
> > > use the error() function.  The change is being made to help out 
> > > end-users that use macros with backtraces in them.  At present, there 
> > > a number of platforms where backtraces through assembler code (e.g. 
> > > glibc thread creation) cause backtraces to get somewhat lost.  When 
> > > the frame code issues the error, any macro issuing the backtrace is 
> > > terminated.  If an end-user is applying such a macro to all threads, 
> > > it ends prematurely for no good reason.  With the change, the message 
> > > is still issued and the backtrace is stopped.
> >
> >
> >
> > Interestingly, a customer of ours reported about a year or two ago
> > a situation similar to this. They were using the backtrace command
> > inside breakpoint commands looking like this:
> >
> >         break somewhere
> >         commands
> >            backtrace
> >            continue
> >         end
> >
> > The idea was that they wanted to see how the program would get to
> > a certain piece of code (in our case raise an exception), and how
> > often. But they didn't want to stop the execution and start debugging.
> > But the unwinder would sometimes be confused, and an error would be
> > raised, and the commands execution would be aborted.
> >
> > We modified the debugger in a rather radical way: We wrapped the
> > backtrace command under control of the catch_error() routine, and
> > transformed any error into a warning. We didn't feel that this would
> > be interesting for the FSF tree, but maybe our assesment was wrong.
> > Let us know if this approach would also be useful, in which case
> > we'll be happy to contribute it.
>
>
> (Somewhere there is a try / finally command patch, just waiting to be 
> integrated.)
>
> How does the following sound:

Sounds fine.  I'll start working on it.  I assume you meant non_fatal_error 
below for the new function that issues the quit.

> - add a new fatal_error():
>
> There should be a new error mechanism that throws a QUIT instead of 
> ERROR.  Code should not normally be catching QUIT (much unfortunately 
> does).  A fatal error is things like: syntax error; no target; lost 
> target.  Things like a memory access violation though are not fatal.
>
> - think about stopping code catching and then discarding QUIT
> Grep for RETURN_MASK_ALL in the sources - it should be RETURN_MASK_ERROR 
> :-/
>
> - modify the backtrace code to catch ERROR, but not QUIT
>
> Along the lines of Joel's suggestion, the backtrace command should catch 
> ERROR (but should not catch QUIT).  That way simple problems don't abort 
> the script but fatal ones do.
>
>
> Why?
>
> Lets try to categorize commands as being of two types:
>
> - display
> These commands print information from the inferior.  In general they 
> don't cause an error - for instance:
>   (gdb) print *(char *)0
>   $1 = <memory error>
> (yes I know, this isn't currently the case :-)
>
> - modify
> These commands try to change the state of GDB or the inferior.  In 
> general problems do lead to an error as not performing the operation 
> puts things into a relatively undefined state.
>
> (The pedant will realize that ``(gdb) print (*(char *)0)++'' can be 
> thought of as a  `modify', lets ignore that in this simple model :-).
>
> The breakpoint command falls into the ``display'' category.
> The up and run commands fall into the ``modify'' category.
>
>
> Why not s/error/warning/:
>
> I'm trying to avoid a bigger mess.  Given a corrupt stack, I'm pretty 
> sure that this:
>
>   (gdb) up
>   Previous frame identical to this frame (corrupt stack?)
>   (gdb) up
>   Initial frame selected; you cannot go up.
>
> (the same error should be printed both times) and this:
>
>   (gdb) frame 0x12345678
>   Previous frame identical to this frame (corrupt stack?)
>   (gdb) frame 0x12345678
>   #1  0x1005e5f8 in fprintf_filtered ....
>
> (the error should be completely suppressed) occur!
>
> Fixing this would mean more radical (but still overdue) changes to both 
> the stack and frame code.
>
> My guess is publish a method:
>
>     int safe_get_prev_frame (this_frame, &prev_frame, &error_if_nonnull)
>
> and use that.
>
> How, if you're up for a challenge.
>
> Andrew