From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25095 invoked by alias); 6 Jan 2015 06:20:48 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 25083 invoked by uid 89); 6 Jan 2015 06:20:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Jan 2015 06:20:45 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1Y8NVR-0002lA-Ms from Yao_Qi@mentor.com ; Mon, 05 Jan 2015 22:20:41 -0800 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.224.2; Mon, 5 Jan 2015 22:20:40 -0800 From: Yao Qi To: Pedro Alves CC: Subject: Re: [PATCH 1/8] gdb.threads/{siginfo-thread.c,watchthreads-reorder.c,ia64-sigill.c} races with GDB References: <1419625871-28848-1-git-send-email-palves@redhat.com> <1419625871-28848-2-git-send-email-palves@redhat.com> Date: Tue, 06 Jan 2015 06:20:00 -0000 In-Reply-To: <1419625871-28848-2-git-send-email-palves@redhat.com> (Pedro Alves's message of "Fri, 26 Dec 2014 20:31:04 +0000") Message-ID: <87egr8v39h.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00067.txt.bz2 Pedro Alves writes: > The issue is that the test program stops GDB before it had a chance of > processing the new thread's clone event: > > (gdb) PASS: gdb.threads/siginfo-threads.exp: get pid > continue > Continuing. > Stopping GDB PID 21541. > Waiting till the threads initialize their TIDs. > FAIL: gdb.threads/siginfo-threads.exp: catch signal 0 (timeout) > > On Linux (at least), new threads start stopped, and the debugger must > resume them. The fix is to make the test program wait for the new > threads to be running before stopping GDB. Looks there is a deadlock. main thread sends SIGSTOP to gdb and calls pthread_cond_wait to wait for being notified by child thread. Child thread is stopped (should be resumed by gdb) and can't notify main thread. The patch looks right to me. --=20 Yao (=E9=BD=90=E5=B0=A7)