This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Unable to restore previously selected frame: Observations
- From: Ruppert <ru at swb dot siemens dot de>
- To: insight at sources dot redhat dot com
- Cc: ru at swb dot siemens dot de
- Date: Tue, 29 Oct 2002 16:45:46 +0100 (MET)
- Subject: Unable to restore previously selected frame: Observations
- Reply-to: Ruppert <ru at swb dot siemens dot de>
Hi,
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