From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87440 invoked by alias); 21 Apr 2015 07:48:09 -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 87430 invoked by uid 89); 21 Apr 2015 07:48:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f49.google.com Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com) (209.85.220.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 21 Apr 2015 07:48:06 +0000 Received: by paboj16 with SMTP id oj16so233429427pab.0 for ; Tue, 21 Apr 2015 00:48:05 -0700 (PDT) X-Received: by 10.68.221.102 with SMTP id qd6mr34756950pbc.119.1429602485132; Tue, 21 Apr 2015 00:48:05 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id ra3sm1120497pbb.23.2015.04.21.00.48.02 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 21 Apr 2015 00:48:04 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Sergio Durigan Junior , Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH v3 00/23] All-stop on top of non-stop References: <1429267521-21047-1-git-send-email-palves@redhat.com> <5534EADB.2040201@gmail.com> <87bniirdxf.fsf@redhat.com> <553526D0.9030802@redhat.com> Date: Tue, 21 Apr 2015 07:48:00 -0000 In-Reply-To: <553526D0.9030802@redhat.com> (Pedro Alves's message of "Mon, 20 Apr 2015 17:18:24 +0100") Message-ID: <86r3rdzzvc.fsf@gmail.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-04/txt/msg00756.txt.bz2 Pedro Alves writes: > I assume you mean you saw this once, and if that if you rerun that > test in particular, the fail goes away. No, I saw these fails very time I run this single test. > >> Note that there is no regression either on >>> aarch64 GNU/Linux with gdbserver. > > Awesome. > >>> >>> (gdb) info threads^M >>> Id Target Id Frame ^M >>> ... >>> 30 Thread 0x2019dff1f0 (LWP 28308) "joinable" 0x0000002000121a68 >>> in clone () from /lib/aarch64-linux-gnu/libc.so.6^ >>> ... >>> GPT: lwp Thread 0x2019dff1f0 (LWP 28308) has no pending signal^M >>> Can't detach Thread 0x2019dff1f0 (LWP 28308): No such process^ >>> (gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: >>> detach >>> >>> Another race problem on attach/detach? > > I think so, yes. The same race that was fixed for regular > resumes, here: > > https://sourceware.org/ml/gdb-patches/2015-03/msg00597.html > > can easily happen when detaching. Say, you have 2 threads in your > program. GDB must detach from each thread individually. So it > starts by detaching from thread 1. And just before detaching > from thread 2, thread 1 causes the whole process to exit. So > the PTRACE_DETACH for thread 2 errors with ESRCH (No such process.) > > Now I don't know is why you would see that on iteration 1 ("iter 1"). > One possibility could be that a thread that has already been > detached crashed the process, because e.g., GDB left breakpoints > inserted in memory by mistake, or something is wrong with > infrun.c:prepare_for_detach, or something else along those lines. > In that case, assuming "ulimit -c unlimited", you'll probably find you ha= ve > a core dump for the crashing inferior. Thanks for the clue. I'll dig it deeper. I'll read these patches today, if I don't see any new problems or questions, these patches are fine to me. --=20 Yao (=E9=BD=90=E5=B0=A7)