Re: Unable to restore previously selected frame: Observations

[Andrew Cagney <ac131313 at redhat dot com>]

I suspect it's insight@.  Switching list back :-)


> about two weeks ago I posted the following note to insight@sorces.redhat.com.
> It deals with a bogus "Unable to restore previously selected frame" warning
> which seems to occur randomly when a function call is made from the
> gdb/insight console.
>
> I found one reason for this; and because it is more a gdb issue than a
> insight issue I thought these observations might be useful:
Can you try reproducing this with more up-to-date sources (preferably 
those from the mainline).  See:

ftp://sources.redhat.com/pub/gdb/snapshots/current/

The frame code is currently undergoing ongoing radical reform. 
Consequently, this problem may or may not still be present.  The global 
variable `selected_frame_level' that you refered to, for instance, has gone.

Andrew


> > I apologize if this is a "known glitch" or if this is considered
> > only a minor problem, but I think that I have made some
> > observations which might be useful to somebody who cares about
> > this kind of things:
> >
> > I am in the process of adapting insight 5.1 to a target monitor,
> > and in doing this I have often encountered this popup window "Unable to 
> > restore previously selected frame". This happens quite often, but not
> > always when I manually enter a function call in insight/gdb.
> >
> > Accidentally I noted that this happens _always_ after I looked
> > for a variable value with the balloon evaluator in insight. The
> > sequence
> >
> >   - put the cursor on some variable name and wait for the
> >     balloon evaluator window which displays the value
> >   - manually enter some function call into the console window
> >   
> > reliably results in this "Unable to restore..." popup.
> >
> > This does not happen when a variable is printed directly in the
> > console window.
> >
> > To be sure that I did not inadvertedly mess up something I tried
> > to do this on a plain vanilla Linux box (also with insight 5.1),
> > and there I see the same behaviour. From this I conclude that this 
> > is a genuine insight (or probably gdb) issue.
> >
> > I poked around a bit with a debugger and found the following:
> >
> > - this is triggered in restore_selected_frame always by the value -1
> >   in the variable "level".
> > - this value gets there in the following way:
> >   - the balloon evaluator invokes varobj_create, and there select_frame
> >     is invoked with -1 given as level argument.
> >   - select_frame puts this in the global variable selected_frame_level
> >   - a manual function call results in the following:
> >        save_inferior_status
> >           record_selected_frame
> >              here the value of selected_frame_level is copied into
> >              inferior_status->selected_level
> >        ... function call ...
> >        restore_inferior_status
> >           restore_selected_frame 
> >           here the value of selected_level is extracted from the
> >           inferior_status structure and find_relative_frame invoked.
> >           This leaves that "level" -1 intact, which leads to the
> >           warning because of the condition "level != 0".
> >           
> > I think this explains the (or at least one) sequence of events which
> > leads to this popup.
> >
> > I don't know much about the code in question, but could this be avoided
> > by not noting the value -1 in the global variable selected_frame_level in
> > function select_frame? "Real" level values are obviously always >= 0, and
> > it may not be reasonable to note this "artificial" level value (-1 seems
> > to mean "unknown level").
> >
> >
> > This may, after all, be considered only a cosmetic issue. But at least
> > it is a bit annoying, and it results in a bogus warning, which may be
> > taken for serious.
> >
> >
> > Regards
> > Dieter Ruppert
> > RTS GmbH
> > Schwieberdingen/Germany
> > ru@swb.siemens.de