From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17265 invoked by alias); 9 Jan 2002 23:40:41 -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 17135 invoked from network); 9 Jan 2002 23:40:37 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 9 Jan 2002 23:40:37 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA03274; Wed, 9 Jan 2002 15:40:34 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.11.6/8.11.6) id g09NeCb01424; Wed, 9 Jan 2002 16:40:12 -0700 Date: Wed, 09 Jan 2002 15:40:00 -0000 From: Kevin Buettner Message-Id: <1020109234011.ZM1423@localhost.localdomain> In-Reply-To: Daniel Jacobowitz "Re: linux-proc readlink patch" (Jan 9, 6:10pm) References: <20020109151622.A842@nevyn.them.org> <3C3CC1CD.798D57DB@redhat.com> <20020109181030.B6397@nevyn.them.org> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Daniel Jacobowitz , Michael Snyder Subject: Re: linux-proc readlink patch Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-01/txt/msg00210.txt.bz2 On Jan 9, 6:10pm, Daniel Jacobowitz wrote: > On Wed, Jan 09, 2002 at 02:18:53PM -0800, Michael Snyder wrote: > > Nope, that's not the semantics. Cleanups are always done, no later than > > when the command is finished executing (if not earlier). I even checked > > to make sure that these were done. There's no memory leak. > > Well, the comments in utils.c are wrong, then :) > > > > (2) It is not, IIRC, always correct in the case of chroots. Handling for > > > this has changed across Linux versions several times. On 2.2 it seems to be > > > correct (to my surprise, actually), but I believe it is not on 2.0. Do we > > > care? Probably not, as 2.0 is now -very- old. > > > > Well, if it fails, the code falls back to using the original /proc name. > > By fails, I meant that the output of readlink was not useful. But I > don't think this is a concern. So the link was just wrong? If so, then opening /proc//exe won't work either, right? If these old kernels managed to somehow open the right file but provide an incorrect link via readlink(), I suppose we could stat() the file to see if it exists. Kevin