Re: Unable to restore previously selected frame: Observations

[Andrew Cagney <ac131313@redhat.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
>> 
>> 
> 
> 
>