From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26329 invoked by alias); 7 Jun 2004 21:53:49 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26320 invoked from network); 7 Jun 2004 21:53:48 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 Jun 2004 21:53:48 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i57Lrmi5027259 for ; Mon, 7 Jun 2004 17:53:48 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i57Lrm008194; Mon, 7 Jun 2004 17:53:48 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i57Lrltn006077; Mon, 7 Jun 2004 17:53:47 -0400 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 9358A80019B; Mon, 7 Jun 2004 17:53:47 -0400 (EDT) Message-ID: <40C4E3EB.1020807@redhat.com> Date: Mon, 07 Jun 2004 21:53:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Cc: msnyder@redhat.com Subject: [RFA]: Additional dead thread patch Content-Type: multipart/mixed; boundary="------------040003040505050801070208" X-SW-Source: 2004-06/txt/msg00140.txt.bz2 This is a multi-part message in MIME format. --------------040003040505050801070208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 725 After updating to current sources today, I have noticed a regression in print-threads.exp which is due to some missing logic in my June 4th patch. The problem is a timing issue (it does not occur for my June 4th build). There is a gdb_assert in thread_from_lwp() which gets triggered because the th_valid flag has not been set for a zombie thread's thread_info struct. This patch fills in the zombie thread's thread_info private area since the information is indeed valid and available. Ok to commit? -- Jeff J. 2004-06-07 Jeff Johnston * thread-db.c (thread_get_info_callback): Fill in the thread_info struct if one exists, even if we are dealing with a zombie thread. --------------040003040505050801070208 Content-Type: text/plain; name="thread-db.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="thread-db.patch" Content-length: 1039 Index: thread-db.c =================================================================== RCS file: /cvs/src/src/gdb/thread-db.c,v retrieving revision 1.41 diff -u -p -r1.41 thread-db.c --- thread-db.c 4 Jun 2004 21:28:15 -0000 1.41 +++ thread-db.c 7 Jun 2004 21:35:57 -0000 @@ -275,12 +275,18 @@ thread_get_info_callback (const td_thrha thread_info = find_thread_pid (thread_ptid); /* In the case of a zombie thread, don't continue. We don't want to - attach to it thinking it is a new thread and we don't want to mark - it as valid. */ + attach to it thinking it is a new thread. */ if (ti.ti_state == TD_THR_UNKNOWN || ti.ti_state == TD_THR_ZOMBIE) { if (infop != NULL) *(struct thread_info **) infop = thread_info; + if (thread_info != NULL) + { + memcpy (&thread_info->private->th, thp, sizeof (*thp)); + thread_info->private->th_valid = 1; + memcpy (&thread_info->private->ti, &ti, sizeof (ti)); + thread_info->private->ti_valid = 1; + } return TD_THR_ZOMBIE; } --------------040003040505050801070208--