Re: [RFA]: issue warnings for frame offenses

[Joel Brobecker <brobecker at gnat dot com>]

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

> Ok to commit?
> 
> 2004-10-26  Jeff Johnston  <jjohnstn@redhat.com>
> 
>         * frame.c (get_prev_frame_1): Change inner frame and equivalent
>         frame tests to issue a warning rather than an error.
>         (get_prev_frame): When backtrace limit is exceeded, terminate
>         with a warning rather than an error.
> 
-- 
Joel