Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Luis Machado <luisgpm@linux.vnet.ibm.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb@sourceware.org
Subject: Re: (maybe) Async mode failures on PPC
Date: Tue, 15 Jul 2008 14:47:00 -0000	[thread overview]
Message-ID: <1216133200.7260.4.camel@gargoyle> (raw)
In-Reply-To: <1216055220.2607.18.camel@gargoyle>

On Mon, 2008-07-14 at 14:06 -0300, Luis Machado wrote:
> Hey Pedro,
> 
> On Mon, 2008-07-14 at 17:57 +0100, Pedro Alves wrote:
> > Hi Luis,
> > 
> > On Monday 14 July 2008 17:31:42, Luis Machado wrote:
> > > Steps to reproduce this failure:
> > >
> > > 1 - Load the watchpoint.exp test binary into gdb.
> > > 2 - start it and next over a few lines.
> > 
> > I can't reproduce it on x86 (sync or async), neither with your
> > recipe or by running the watchpoint.exp test.
> 
> It seems to be a ppc-specific thing. I forgot to mention that you need
> to place a watchpoint on variable "ptr1" to trigger this. When no
> watchpoints are inserted, it runs as expected. And this is sync mode,
> i
> did not turn async on, and i presume it's off by default, like it was
> until recently.
> 
> > :-(
> > 
> > The "Target is executing" notice comes from
> frame.c:get_current_frame.
> > 
> > I couldn't figure out for sure from your description of the
> > problem if this only happens in async, or if it happen in sync as
> well,
> > but I understood async only.
> > 
> > Why is GDB trying to get the current frame of an executing
> > thread, or why does GDB think that the current thread is
> > executing at this point, if it isn't?
> > 
> > Can you do a bit of debugging and figure out what is the
> > code path that ended up triggering the first error?
> > get_current_frame is called from too many places to be able
> > to do an educated guess.
> 
> Yes, sorry. I was just wondering if anyone else was having the same
> problem and did not provide much info about it. I'll dig into it and
> will provide the code path for the error as it seems to be a
> regression.
> But i feel it's related somehow to watchpoints.
> 
> Regards,
> Luis

Here is a patch i discussed with Pedro to fix this regression. Tested
and nothing showed up in the testsuite.

Is this OK?


2008-07-15  Luis Machado  <luisgpm@br.ibm.com>

	* infrun.c (handle_inferior_event): reinit_frame_cache before
	handling events on threads. 

Index: gdb/infrun.c
===================================================================
--- gdb.orig/infrun.c	2008-07-15 09:36:19.000000000 -0500
+++ gdb/infrun.c	2008-07-15 09:37:20.000000000 -0500
@@ -1828,6 +1828,29 @@
 
   adjust_pc_after_break (ecs);
 
+  reinit_frame_cache ();
+
+  /* If it's a new process, add it to the thread database */
+
+  ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid)
+			   && !ptid_equal (ecs->ptid, minus_one_ptid)
+			   && !in_thread_list (ecs->ptid));
+
+  if (ecs->ws.kind != TARGET_WAITKIND_EXITED
+      && ecs->ws.kind != TARGET_WAITKIND_SIGNALLED && ecs->new_thread_event)
+    add_thread (ecs->ptid);
+
+  if (ecs->ws.kind != TARGET_WAITKIND_IGNORE)
+    {
+      /* Mark the non-executing threads accordingly.  */
+      if (!non_stop
+ 	  || ecs->ws.kind == TARGET_WAITKIND_EXITED
+ 	  || ecs->ws.kind == TARGET_WAITKIND_SIGNALLED)
+ 	set_executing (pid_to_ptid (-1), 0);
+      else
+ 	set_executing (ecs->ptid, 0);
+    }
+
   switch (infwait_state)
     {
     case infwait_thread_hop_state:
@@ -1867,29 +1890,6 @@
     }
   infwait_state = infwait_normal_state;
 
-  reinit_frame_cache ();
-
-  /* If it's a new process, add it to the thread database */
-
-  ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid)
-			   && !ptid_equal (ecs->ptid, minus_one_ptid)
-			   && !in_thread_list (ecs->ptid));
-
-  if (ecs->ws.kind != TARGET_WAITKIND_EXITED
-      && ecs->ws.kind != TARGET_WAITKIND_SIGNALLED && ecs->new_thread_event)
-    add_thread (ecs->ptid);
-
-  if (ecs->ws.kind != TARGET_WAITKIND_IGNORE)
-    {
-      /* Mark the non-executing threads accordingly.  */
-      if (!non_stop
- 	  || ecs->ws.kind == TARGET_WAITKIND_EXITED
- 	  || ecs->ws.kind == TARGET_WAITKIND_SIGNALLED)
- 	set_executing (pid_to_ptid (-1), 0);
-      else
- 	set_executing (ecs->ptid, 0);
-    }
-
   switch (ecs->ws.kind)
     {
     case TARGET_WAITKIND_LOADED:



  reply	other threads:[~2008-07-15 14:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-14 15:45 Luis Machado
2008-07-14 16:32 ` Luis Machado
2008-07-14 16:58   ` Pedro Alves
2008-07-14 17:07     ` Luis Machado
2008-07-15 14:47       ` Luis Machado [this message]
2008-07-15 16:34         ` Pedro Alves
2008-07-15 16:40           ` Daniel Jacobowitz
2008-07-15 16:42             ` Pedro Alves
2008-07-15 16:45         ` Luis Machado
2008-07-15 16:49           ` Daniel Jacobowitz
2008-07-15 17:30             ` Luis Machado
2008-07-14 21:37     ` Andreas Schwab

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=1216133200.7260.4.camel@gargoyle \
    --to=luisgpm@linux.vnet.ibm.com \
    --cc=gdb@sourceware.org \
    --cc=pedro@codesourcery.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