This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Unable to restore previously selected frame: Observations


Hi,

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:



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]