From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23199 invoked by alias); 18 Feb 2011 19:30:45 -0000 Received: (qmail 23190 invoked by uid 22791); 18 Feb 2011 19:30:44 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Feb 2011 19:30:40 +0000 Received: (qmail 10070 invoked from network); 18 Feb 2011 19:30:38 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Feb 2011 19:30:38 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: New testsuite errors with gdbserver (remote) Date: Fri, 18 Feb 2011 19:30:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.6.0; x86_64; ; ) Cc: Keith Seitz , Michael Snyder , swagiaal@redhat.com, oguzkayral@gmail.com References: <4D5C71F6.80208@vmware.com> <4D5D6D83.8030302@vmware.com> <4D5D8974.5030205@redhat.com> In-Reply-To: <4D5D8974.5030205@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102181930.30941.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00108.txt.bz2 On Thursday 17 February 2011 20:47:48, Keith Seitz wrote: > On 02/17/2011 10:48 AM, Michael Snyder wrote: > > Somewhat to my surprise, these new failures narrow down to this change: > > I've given this a peek, and here's what I've found out... > > When the exit notification is sent, and python picks it up, it is > setting up the python environment (architecture and language). The > python exit callback does this by calling get_current_arch. > > The problem is that (long before this) wait_for_inferior sets the > inferior with TID = 0. It is this inferior object that is then passed > around for the event notification. Alas, unlike natives, where the > inferior is popped, the inferior is still around. > > As a result, target_has_stack goes to check the thread status and cannot > find the appropriate thread (since the one in the list hasn't been > cleared). This leads to the internal error you're seeing. > > I'm not sure how valid it is to call get_current_arch from an exit > event. Maybe it is. Maybe it isn't. Someone who knows a lot more about > this is going to have to investigate this or guide me. /* Return "current" architecture. If the target is running, this is the architecture of the selected frame. Otherwise, the "current" architecture defaults to the target architecture. This function should normally be called solely by the command interpreter routines to determine the architecture to execute a command in. */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ struct gdbarch * get_current_arch (void) The exited observer are called at other times, not when preparing to execute a command in. It is quite bogus to assume the current architecture, frame and language have anything to do with the inferior that has been passed is as argument to the observer. > @@ -116,7 +116,7 @@ python_inferior_exit (struct inferior *i > ptid_t ptidp; > struct target_waitstatus status; > > - cleanup = ensure_python_env (get_current_arch (), current_language); > + cleanup = ensure_python_env (target_gdbarch, current_language); > > get_last_target_status (&ptidp, &status); I can't say that I'm very familiar with most of the python layer code, but, why does this observer need to call ensure_python_env in the first place? Or if it does, why doesn't it call it with python_gdbarch like other places in py-inferior that are internal helpers, not implementing a user command? -- Pedro Alves