This is the mail archive of the insight@sources.redhat.com mailing list for the Insight 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,


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]