This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

yet another clone handling fix

Something else putting the core under control of stopping
all threads revealed.  We'd end up with new threads stuck stopped,
because I missed that lin_lwp_attach_lwp forces resume_kind
to resume_stop.  I may revisit that later.

Tested on x86_64-linux and applied.

Pedro Alves

2011-10-24  Pedro Alves  <>

	* linux-nat.c (linux_handle_extended_wait): When handling a clone
	event, in non-stop, if not stopping, make sure the new lwp has
	last_resume_kind set to resume_continue.  Assert that when we're
	resuming the new lwp, its last_resume_kind is resume_continue.

 gdb/linux-nat.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: src/gdb/linux-nat.c
--- src.orig/gdb/linux-nat.c	2011-10-24 14:53:45.730715043 +0100
+++ src/gdb/linux-nat.c	2011-10-24 15:23:01.200715304 +0100
@@ -2289,6 +2289,9 @@ linux_handle_extended_wait (struct lwp_i
 		  set_running (new_lp->ptid, 1);
 		  set_executing (new_lp->ptid, 1);
+		  /* thread_db_attach_lwp -> lin_lwp_attach_lwp forced
+		     resume_stop.  */
+		  new_lp->last_resume_kind = resume_continue;
@@ -2316,6 +2319,7 @@ linux_handle_extended_wait (struct lwp_i
 	      if (status == 0)
+		  gdb_assert (new_lp->last_resume_kind == resume_continue);
 		  if (debug_linux_nat)
 		    fprintf_unfiltered (gdb_stdlog,
 					"LHEW: resuming new LWP %ld\n",

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]