From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19277 invoked by alias); 17 Feb 2011 20:48:02 -0000 Received: (qmail 19217 invoked by uid 22791); 17 Feb 2011 20:48:01 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Feb 2011 20:47:54 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p1HKlpjB029207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Feb 2011 15:47:51 -0500 Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p1HKlmUx014886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 15:47:50 -0500 Message-ID: <4D5D8974.5030205@redhat.com> Date: Thu, 17 Feb 2011 20:48:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Michael Snyder CC: "gdb@sourceware.org" , swagiaal@redhat.com, oguzkayral@gmail.com Subject: Re: New testsuite errors with gdbserver (remote) References: <4D5C71F6.80208@vmware.com> <4D5C7552.4010708@vmware.com> <4D5C8312.4030701@vmware.com> <4D5D6D83.8030302@vmware.com> In-Reply-To: <4D5D6D83.8030302@vmware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00104.txt.bz2 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. Nonetheless, if you pass target_gdbarch instead to ensure_python_env in python_inferior_exit (in python/py_inferior.c), things will behave much better. Once again, I don't know if this is strictly correct, but it should at least get you going with gdbserver again. I hope this leads someone to a better solution. Keith Index: python/py-inferior.c =================================================================== RCS file: /cvs/src/src/gdb/python/py-inferior.c,v retrieving revision 1.5 diff -u -p -r1.5 py-inferior.c --- python/py-inferior.c 4 Feb 2011 21:54:16 -0000 1.5 +++ python/py-inferior.c 17 Feb 2011 20:46:08 -0000 @@ -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);