From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57236 invoked by alias); 8 Mar 2015 21:48:23 -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 57219 invoked by uid 89); 8 Mar 2015 21:48:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 08 Mar 2015 21:48:15 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t28LmE6k031940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 8 Mar 2015 17:48:14 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t28LmC0i009719; Sun, 8 Mar 2015 17:48:13 -0400 Message-ID: <54FCC39C.6090302@redhat.com> Date: Sun, 08 Mar 2015 21:48:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Kettenis CC: gdb-patches@sourceware.org Subject: Re: [PATCH 2/6] Introduce throw_ptrace_error References: <1425671886-7798-1-git-send-email-palves@redhat.com> <1425671886-7798-3-git-send-email-palves@redhat.com> <201503062103.t26L3tef004332@glazunov.sibelius.xs4all.nl> <54FA1EB3.2050706@redhat.com> <201503082029.t28KToYr022852@glazunov.sibelius.xs4all.nl> In-Reply-To: <201503082029.t28KToYr022852@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00205.txt.bz2 On 03/08/2015 08:29 PM, Mark Kettenis wrote: > I think your interpretation of ESRCH is too Linux-centric. You're > once again duct-taping around the Linux kernel's whoefully > insufficient threads debugging capabilities. Nice. > It really should not be > possible for a thread to just disappear without the debugger being > notified. Do I sound like a broken record? Sorry, but yes, you do. ;-) The debugger is notified. It's just a fact that a process can die (and become zombie) even while it was _stopped_ under ptrace control. That's a race you can't prevent, only cope with. I found NetBSD 5.1 in the GCC compile farm, and I see ESRCH there too: -bash-4.2$ uname -a NetBSD gcc70.fsffrance.org 5.1 NetBSD 5.1 (GENERIC) #0: Sat Nov 6 13:19:33 UTC 2010 builds@b6.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/amd64/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/amd64/compile/GENERIC amd64 -bash-4.2$ gdb ./foo GNU gdb 6.5 ... (gdb) start Breakpoint 1 at 0x400894: file foo.c, line 5. Starting program: /home/palves/foo main () at foo.c:5 5 return 0; (gdb) p getpid () $1 = 24557 (gdb) shell kill -9 24557 (gdb) c Continuing. ptrace: No such process. (gdb) But even if some ptrace-based OS uses a different errno for that (which I doubt), we can just tweak throw_ptrace_error (a centralized place, yay!) to look for a different errno value. So what does OpenBSD's ptrace return in the test above? > I think at this point the right approach is to make > linux_resume_one_lwp() call ptrace() directly instead of calling down > into the inf_ptrace_resume(). That way you can simply check errno in > the place where it matters. No, your "simply" is not simple as you imply. There can be any number of ptrace calls that fail before the PT_CONTINUE in inf_ptrace_resume is reached. And whether to ignore the error should be left to some caller higher up on the call chain. That was the _whole point_ of this fuller fix, as I explained throughout the series. E.g., the ptrace call that fails can be the one that tries to write debug registers to the inferior, normal registers, reading the auxv, any memory read/write, whatever. Any ptrace error that throws ends up in the generic perror_with_name today, after the series, they'll end up in throw_ptrace_error instead, a single place we can add more context info to the error thrown. How is that a bad thing? Thanks, Pedro Alves