From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18843 invoked by alias); 9 Jan 2002 22:24:07 -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 18786 invoked from network); 9 Jan 2002 22:24:02 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 9 Jan 2002 22:24:02 -0000 Received: from redhat.com (reddwarf.cygnus.com [205.180.231.12]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA24985; Wed, 9 Jan 2002 14:23:58 -0800 (PST) Message-ID: <3C3CC1CD.798D57DB@redhat.com> Date: Wed, 09 Jan 2002 14:24:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: linux-proc readlink patch References: <20020109151622.A842@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00199.txt.bz2 Daniel Jacobowitz wrote: > > This patch: > > 2002-01-08 Michael Snyder > > * linux-proc.c (child_pid_to_exec_file): Use readlink to get the > real name of the executable, rather than the /proc name. > > (which I never saw posted on gdb-patches; was that an artifact of the email > breakage yesterday?) Coulda been. I sent so many yesterday (and had to resend so many of them) that I can't remember. > > seems to have at least one problem. > > (1) It introduces a memory leak, if I understand the semantics of cleanups > correctly. make_cleanup's cleanups will only be called (according to the > comment in utils.c) after a failed command. 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. > (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.