From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28575 invoked by alias); 29 Nov 2002 04:15:11 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 28567 invoked from network); 29 Nov 2002 04:15:09 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 29 Nov 2002 04:15:09 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A6A783F30; Thu, 28 Nov 2002 23:14:52 -0500 (EST) Message-ID: <3DE6E9BC.1000702@redhat.com> Date: Thu, 28 Nov 2002 20:15:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruppert Cc: insight@sources.redhat.com Subject: Re: Unable to restore previously selected frame: Observations References: <200211131719.gADHJYu14688@haiti.swb.siemens.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-q4/txt/msg00130.txt.bz2 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 >> >> > > >