Re: [downstream patch FYI] workaround stale frame_info * (PR 13866)

[Pedro Alves <palves@redhat.com>]

On 06/06/2012 08:38 PM, Tom Tromey wrote:

> Despite the difficulties perhaps we should try to write a static
> analyzer for this.  I am not sure if it could be made reliable enough,
> but maybe it could.  The problem cases are when the analyzer must
> account for cleanups -- but in this case we might be able to get away
> with ignoring them.


If that doesn't work, or if it's too much trouble, we could consider putting
in a variant of my validation patch.  Instead of garbage collecting dead frames
at some specific points, keep say, a FIFO of the last N dead frames (don't free
them, but mark them dead, catching uses of those).  N could be low.  That'd
keep the extra memory bounded.  If this is considered expensive (unlikely),
we could guard it behind the new --development flag (kind of like
checking in gcc).

> Another idea is to simply get rid of frame_info and have only a
> frame_id-based API.

Most, a large majority of frame_info objects I see (when not a transient
use like get_current_frame passed directly to some frame.c function) of what I
see is in the unwinders, where that'd unnecessary, and wouldn't really work.
Most other places tend to already be careful with frame_info lifetime.  There's
execution commands (of which "until" was particularly bad), and a handful of
other things.  There are some paths in handle_inferior_event on software
single-step targets that might be hitting stale frame_info (hey, where
else would problems be, right?), but in all honesty, I don't think there
are that many related lurking bugs to worry that much about.

-- 
Pedro Alves