Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Keith Seitz <keiths@redhat.com>
To: Michael Snyder <msnyder@vmware.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>,
	swagiaal@redhat.com,        oguzkayral@gmail.com
Subject: Re: New testsuite errors with gdbserver (remote)
Date: Thu, 17 Feb 2011 20:48:00 -0000	[thread overview]
Message-ID: <4D5D8974.5030205@redhat.com> (raw)
In-Reply-To: <4D5D6D83.8030302@vmware.com>

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


  reply	other threads:[~2011-02-17 20:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-17  0:55 Michael Snyder
2011-02-17  1:09 ` Michael Snyder
2011-02-17  2:08   ` Michael Snyder
2011-02-17 18:48     ` Michael Snyder
2011-02-17 20:48       ` Keith Seitz [this message]
2011-02-18 16:48         ` [RFA] Fix for " Pierre Muller
2011-02-18 19:30         ` New " Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D5D8974.5030205@redhat.com \
    --to=keiths@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=msnyder@vmware.com \
    --cc=oguzkayral@gmail.com \
    --cc=swagiaal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox