From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751539AbWHAAIh (ORCPT ); Mon, 31 Jul 2006 20:08:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751543AbWHAAIh (ORCPT ); Mon, 31 Jul 2006 20:08:37 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]:24839 "EHLO nf-out-0910.google.com") by vger.kernel.org with ESMTP id S1751525AbWHAAIg (ORCPT ); Mon, 31 Jul 2006 20:08:36 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZbJ9dLgA+p6m+1L5hE/x0oN8Y6/6+UjqPCHsIL30wa7HXesl3mf90j7wIu1m6GAalL/+ghFESQ+irQ0ugQWYGlN+s9llUpZlWVsH+Yks/SON45QCzD5WjYuU4YJZSWf2L/503XhsieSmI+kNH/HWQqga5J9beVvGKJpdziX+CBI= Message-ID: <787b0d920607311708y3642e41cue49cd47ccc39e77d@mail.gmail.com> Date: Mon, 31 Jul 2006 20:08:35 -0400 From: "Albert Cahalan" To: "Albert Cahalan" , torvalds@osdl.org, alan@lxorguk.ukuu.org.uk, ak@suse.de, mingo@elte.hu, arjan@infradead.org, akpm@osdl.org, linux-kernel@vger.kernel.org, roland@redhat.com Subject: Re: ptrace bugs and related problems In-Reply-To: <20060731190018.GA13735@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <787b0d920607262355x3f669f0ap544e3166be2dca21@mail.gmail.com> <20060727203128.GA26390@nevyn.them.org> <787b0d920607271817u4978d2bdiac261d916971c1b3@mail.gmail.com> <20060728034741.GA3372@nevyn.them.org> <787b0d920607281528w56472db2u81268aad523d5c72@mail.gmail.com> <20060731190018.GA13735@nevyn.them.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 7/31/06, Daniel Jacobowitz wrote: > On Fri, Jul 28, 2006 at 06:28:34PM -0400, Albert Cahalan wrote: > [somebody - lost ref] > > >Or just present things as if the leader task did the execve, which is > > >effectively what happens, and what I thought would happen for ptrace > > >too. > > > > That makes things even weirder. A successful execve done in one > > thread appears to be done by another (which might not be > > traced if the debugger was a bit odd), while a failing execve > > appears... where? > > Not at all, unless you're doing syscall tracing, I don't think. The > exec notification is after the mm is replaced. Syscall tracing is pretty much a given I think. There are numerous reasons to use it, not all of which I remember. I think some of the reasons are related to single-stepping over sysenter, syscall, and int 0x80. The execve event is unreliable anyway. Thus, it is necessary to use syscall tracing. So that leaves a debugger with the weirdness of a system call that enters via one task and then exits via a different task. That different task might have been running (a syscall exit without an entry within that task) or in some unrelated syscall (whee... the syscall number suddenly changed) or even racing in execve. > > >> PTRACE_GETSIGINFO has 0x0605 as si_code when a process exits. > > >> This is not defined anywhere. > > > > > >It's garbage. PTRACE_GETSIGINFO is only valid after the process stops > > >with a signal. > > > > The process does indeed stop with a signal. It gets SIGTRAP > > as part of sending the ptrace event. > > Sure, but you must know what I meant. PTRACE_GETSIGINFO is only valid > when there is a real signal, i.e. generated by something other than > ptrace. Which is true whenever wait reports a signal without any of > the special event bits set (except for the legacy SIGTRAP on execve). That sucks. I like converting si_code to something readable that I can present to the user. Well, it seems to work anyway. The main failure is that an access to unmapped memory does not give 3 distinct codes for read/write/execute.