From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5593 invoked by alias); 17 Sep 2005 22:18:30 -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 5583 invoked by uid 22791); 17 Sep 2005 22:18:26 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 17 Sep 2005 22:18:26 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id j8HMHiSr009424; Sun, 18 Sep 2005 00:17:44 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j8HMHi89016035; Sun, 18 Sep 2005 00:17:44 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j8HMHh3R005674; Sun, 18 Sep 2005 00:17:43 +0200 (CEST) Date: Sat, 17 Sep 2005 22:18:00 -0000 Message-Id: <200509172217.j8HMHh3R005674@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: qpan@mvista.com, gdb-patches@sources.redhat.com, qunyingpan@gmail.com In-reply-to: <20050917215830.GG8777@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 17 Sep 2005 17:58:30 -0400) Subject: Re: Patch: fix gdb_gcore.sh failure in ash/dash References: <432240C1.9000308@mvista.com> <20050917215830.GG8777@nevyn.them.org> X-SW-Source: 2005-09/txt/msg00131.txt.bz2 > Date: Sat, 17 Sep 2005 17:58:30 -0400 > From: Daniel Jacobowitz > > On Fri, Sep 09, 2005 at 07:11:13PM -0700, Qunying Pan wrote: > > Hi, > > > > Running gdb_gcore.sh in ash/dash fails with message "Hangup detected on > > fd 0". The following patch fixes the problem. Acceptable? > > Let's just use a tempfile. This patch also makes one other change in > behavior: it uses gdb from $PATH instead of hardcoding /usr/bin, since > I needed that to test it and it seems more reasonable. > > Anyone have comments on this patch? I think using a temporary file is a good idea, but if I read your patch correctly, it seems the temporary file is created in the current directory, which might not be writable. Another problem is that the name is predictable, which is a potential security risk. Assuming mktemp(1) is available is probably not a good idea, but it'd be nice to use it if it's avaiable. Mark