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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

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.

No testsuite case, waiting on MAY_FOLLOW_EXEC resolution below.


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.


Regards,
Jan

[-- Attachment #2: gdb-cvs20060722-exec_reset.patch --]
[-- Type: text/plain, Size: 1102 bytes --]

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182116

exec() causes fatal:
	Cannot find user-level thread for LWP 4256: generic error
Patch below does not enable the new process tracing but it will not crash.
MAY_FOLLOW_EXEC enable for GNU/Linux was discouraged by Daniel Jacobowitz.
	<20060721184421.GA22820@nevyn.them.org>


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	22 Jul 2006 12:17:50 -0000
@@ -875,6 +875,14 @@ 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)
+    {
+      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.  */