Re: Unable to restore previously selected frame: Observations

Re: Unable to restore previously selected frame: Observations

[Ruppert]

Hi,

Andrew Cagney wrote:
...

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

Sorry for the delay. I just tried insight+dejagnu-20021129, and there
the problem is indeed gone. Thus, no need to worry about this.
Thanks for the hint!

Best Regards
D.Ruppert
ru@swb.siemens.de

Re: Unable to restore previously selected frame: Observations

[Andrew Cagney]

> 
> Sorry for the delay. I just tried insight+dejagnu-20021129, and there
> the problem is indeed gone. Thus, no need to worry about this.
> Thanks for the hint!

That's good news.  It means that the (slow painful) frame overhaul 
really is flushing out long standing bugs.

Andrew

Re: Unable to restore previously selected frame: Observations

[Andrew Cagney]

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

Unable to restore previously selected frame: Observations

[Ruppert]

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