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]

[patch] 7.3 regression for corrupted core files threads


Hi,

while this feature was great
	PR corefile/8210: Linux core files should use linux-thread-db.c
	http://sourceware.org/ml/gdb-patches/2010-08/msg00208.html

it has caused a regression - if the thread list is corrupted GDB displayed LWP
list before but current GDB does not display even the LWP list.

This fix does:

-[Thread debugging using libthread_db enabled]^M
-Using host libthread_db library "/lib64/libthread_db.so.1".^M
-Cannot find new threads: debugger service failed^M
+warning: td_ta_thr_iter failed: debugger service failed^M
+warning: td_ta_thr_iter failed: debugger service failed^M
+warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.^M
+warning: td_ta_thr_iter failed: debugger service failed^M
+warning: td_ta_thr_iter failed: debugger service failed^M
+warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.^M
 Core was generated by `gcore-thread'.^M
 Program terminated with signal 5, Trace/breakpoint trap.^M
 #0  thread2 (arg=0xdeadbeef) at ./gdb.threads/pthreads.c:90^M
 90       int k = 0;^M
 (gdb) PASS: gdb.threads/gcore-thread.exp: core0file: re-load generated corefile
 info threads^M
-Cannot find new threads: debugger service failed^M
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-(gdb) FAIL: gdb.threads/gcore-thread.exp: core0file: corefile contains at least two threads
+  Id   Target Id         Frame ^M
+  3    LWP 4644          0x00007ffff75c99bd in nanosleep () at ../sysdeps/unix/syscall-template.S:82^M
+  2    LWP 4649          0x00007ffff75c99bd in nanosleep () at ../sysdeps/unix/syscall-template.S:82^M
+* 1    LWP 4650          thread2 (arg=0xdeadbeef) at ./gdb.threads/pthreads.c:90^M
+(gdb) PASS: gdb.threads/gcore-thread.exp: core0file: corefile contains at least two threads

No regressions on {x86_64,x86_64-m32,i686}-fedora17-linux-gnu.


Thanks,
Jan


gdb/
2012-04-17  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* linux-thread-db.c (find_new_threads_once): New prototype.
	(try_thread_db_load_1): Try to call find_new_threads_once.

gdb/testsuite/
2012-04-17  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.threads/gcore-thread.exp: Remove variable libthread_db_seen.
	Wrap the test into loop for corefile and core0file.

diff --git a/gdb/linux-thread-db.c b/gdb/linux-thread-db.c
index 4d09c6e..3da206c 100644
--- a/gdb/linux-thread-db.c
+++ b/gdb/linux-thread-db.c
@@ -185,6 +185,8 @@ struct thread_db_info
 struct thread_db_info *thread_db_list;
 
 static void thread_db_find_new_threads_1 (ptid_t ptid);
+static int find_new_threads_once (struct thread_db_info *info, int iteration,
+				  td_err_e *errp);
 static void thread_db_find_new_threads_2 (ptid_t ptid, int until_no_new);
 
 /* Add the current inferior to the list of processes using libpthread.
@@ -739,6 +741,17 @@ try_thread_db_load_1 (struct thread_db_info *info)
   info->td_thr_event_enable_p = dlsym (info->handle, "td_thr_event_enable");
   info->td_thr_tls_get_addr_p = dlsym (info->handle, "td_thr_tls_get_addr");
 
+  find_new_threads_once (info, 0, &err);
+  if (err != TD_OK)
+    {
+      /* Even if libthread_db initializes in the case the thread list is
+	 corrupted it would not list any threads.  Fall back to list at least
+	 LWPs in such case.  */
+
+      warning (_("td_ta_thr_iter failed: %s"), thread_db_err_str (err));
+      return 0;
+    }
+
   printf_unfiltered (_("[Thread debugging using libthread_db enabled]\n"));
 
   if (libthread_db_debug || *libthread_db_search_path)
diff --git a/gdb/testsuite/gdb.threads/gcore-thread.exp b/gdb/testsuite/gdb.threads/gcore-thread.exp
index dfb2314..7727e93 100644
--- a/gdb/testsuite/gdb.threads/gcore-thread.exp
+++ b/gdb/testsuite/gdb.threads/gcore-thread.exp
@@ -143,11 +143,9 @@ proc load_core { corefile } {
     global gdb_prompt
     global libthread_db_seen
 
-    set libthread_db_seen 0
     gdb_test_multiple "core $corefile" \
 	"re-load generated corefile" {
 	    -re "\\\[Thread debugging using \[^ \r\n\]* enabled\\\]\r\n" {
-		set libthread_db_seen 1
 		exp_continue
 	    }
 	    -re " is not a core dump:.*\r\n$gdb_prompt $" {
@@ -170,39 +168,27 @@ proc load_core { corefile } {
     return 1
 }
 
-if ![load_core $corefile] {
-    return
-}
-
-# FIXME: now what can we test about the thread state?
-# We do not know for certain that there should be at least 
-# three threads, because who knows what kind of many-to-one
-# mapping various OS's may do?  Let's assume that there must
-# be at least two threads:
-
-gdb_test "info threads" ".*${nl}  2 ${horiz}${nl}\\* 1 .*" \
-	"corefile contains at least two threads"
-
-# One thread in the corefile should be in the "thread2" function.
-
-gdb_test "info threads" ".* thread2 .*" \
-	"a corefile thread is executing thread2"
+foreach name { corefile core0file } { with_test_prefix $name {
+    if ![load_core [subst $$name]] {
+	continue
+    }
 
-# The thread2 thread should be marked as the current thread.
+    # FIXME: now what can we test about the thread state?
+    # We do not know for certain that there should be at least 
+    # three threads, because who knows what kind of many-to-one
+    # mapping various OS's may do?  Let's assume that there must
+    # be at least two threads:
 
-gdb_test "info threads" ".*${nl}\\* ${horiz} thread2 .*" \
-	"thread2 is current thread in corefile"
+    gdb_test "info threads" ".*${nl}  2 ${horiz}${nl}\\* 1 .*" \
+	    "corefile contains at least two threads"
 
+    # One thread in the corefile should be in the "thread2" function.
 
-# Test the uninitialized thread list.
+    gdb_test "info threads" ".* thread2 .*" \
+	    "a corefile thread is executing thread2"
 
-if {"$core0file" != "" && [load_core $core0file]} {
-    set test "zeroed-threads cannot be listed"
+    # The thread2 thread should be marked as the current thread.
 
-    if {!$libthread_db_seen} {
-	verbose -log "No libthread_db loaded - -Wl,-z,relro compilation?"
-	xfail $test
-    } else {
-	gdb_test "info threads" "Cannot find new threads: .*" $test
-    }
-}
+    gdb_test "info threads" ".*${nl}\\* ${horiz} thread2 .*" \
+	    "thread2 is current thread in corefile"
+}}


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