This is the mail archive of the gdb-patches@sourceware.org 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]

Re: RFC: Fix crash on i386 (%gs-)threaded programs using execve(2)


On Sat, Jul 22, 2006 at 02:31:02PM +0200, Jan Kratochvil wrote:
> Hi Daniel,
> 
> please commit if appropriate:
> 
> Created the attached minimal patch fixing the gdb lockup.
> 
> 2006-07-22  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* linux-thread-db.c (thread_db_wait): Avoid locking up on stale
> 	threading state after TARGET_WAITKIND_EXECD.

Thanks.  I've committed the attached version; I played around with it a
little bit, and discovered that you couldn't re-run unless you remember
to remove the thread breakpoints too.

> On Fri, 21 Jul 2006 20:44:21 +0200, Daniel Jacobowitz wrote:
> ...
> > Turning on MAY_FOLLOW_EXEC is not a good idea.  No one really knows how
> > that behavior works, a lot of it doesn't, and the way it implicitly
> > changes the symbol file is very disorienting.  Please don't mix it up
> > with the fix for your current bug.
> 
> Still I am for MAY_FOLLOW_EXEC as it improves the user experience and makes
> debugging of exec()ing processes much more convenient - without having to find
> out how each child gets executed and replay such conditions by hand.
> 
> As gdb-6.5 has been released and the MAY_FOLLOW_EXEC feature IMO generally
> works for GNU/Linux - isn't appropriate to enable it and settle it down?
> I would even like to fix any issues possibly roaring its head.

Does anyone else have an opinion on this?  I'm starting to think you're
right - we should turn it on, invite people to use it, and see what
happens.

The reason I find it so disorienting is this:

% gdb file1

(gdb) run
[starts file1]
[file1 execs file2]
[file2 exits]

(gdb) run
[file2 starts instead of file1!]

I don't know if it should do that or not.  I tend to use "run" a lot
and want to get back to the beginning of my debug session.

-- 
Daniel Jacobowitz
CodeSourcery

2006-07-24  Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Daniel Jacobowitz  <dan@codesourcery.com>

	* linux-thread-db.c (thread_db_wait): Remove libthread_db
	after exec events.

Index: linux-thread-db.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-thread-db.c,v
retrieving revision 1.17
diff -u -p -r1.17 linux-thread-db.c
--- linux-thread-db.c	18 Jul 2006 22:53:20 -0000	1.17
+++ linux-thread-db.c	24 Jul 2006 18:56:24 -0000
@@ -875,6 +875,15 @@ thread_db_wait (ptid_t ptid, struct targ
   if (ourstatus->kind == TARGET_WAITKIND_EXITED)
     return pid_to_ptid (-1);
 
+  if (ourstatus->kind == TARGET_WAITKIND_EXECD)
+    {
+      remove_thread_event_breakpoints ();
+      unpush_target (&thread_db_ops);
+      using_thread_db = 0;
+
+      return pid_to_ptid (GET_PID (ptid));
+    }
+
   if (ourstatus->kind == TARGET_WAITKIND_STOPPED
       && ourstatus->value.sig == TARGET_SIGNAL_TRAP)
     /* Check for a thread event.  */


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