From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21398 invoked by alias); 6 Dec 2008 15:42:46 -0000 Received: (qmail 21389 invoked by uid 22791); 6 Dec 2008 15:42:45 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 06 Dec 2008 15:41:57 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id mB6Fenj6006174; Sat, 6 Dec 2008 16:40:49 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id mB6FemZD011819; Sat, 6 Dec 2008 16:40:48 +0100 (CET) Date: Sat, 06 Dec 2008 15:42:00 -0000 Message-Id: <200812061540.mB6FemZD011819@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: tromey@redhat.com CC: gdb-patches@sourceware.org In-reply-to: (message from Tom Tromey on Fri, 05 Dec 2008 17:38:13 -0700) Subject: Re: RFA: close-on-exec internal file descriptors References: 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 X-SW-Source: 2008-12/txt/msg00111.txt.bz2 > From: Tom Tromey > Date: Fri, 05 Dec 2008 17:38:13 -0700 > > A few weeks ago, someone on irc pointed out that gdb leaks file > descriptors to its child processes. One simple way to see this is to > start gdb with an exec and then shell out: > > opsy. gdb /tmp/r > [...] > (gdb) shell ls -l /proc/$$/fd > total 0 > lrwx------ 1 tromey tromey 64 2008-12-05 17:10 0 -> /dev/pts/1 > lrwx------ 1 tromey tromey 64 2008-12-05 17:10 1 -> /dev/pts/1 > lrwx------ 1 tromey tromey 64 2008-12-05 17:10 2 -> /dev/pts/1 > lr-x------ 1 tromey tromey 64 2008-12-05 17:10 3 -> pipe:[1100229] > l-wx------ 1 tromey tromey 64 2008-12-05 17:10 4 -> pipe:[1100229] > lr-x------ 1 tromey tromey 64 2008-12-05 17:10 5 -> /proc/8096/fd > > I believe those 'pipe' entries are from the call to pipe in > linux-nat.c:linux_nat_set_async. > > This patch fixes this problem by introducing new wrapper functions > which create close-on-exec file descriptors. Then, these functions > are used everywhere in gdb. After this patch, these wrapper functions > should be used in all new code as well. > > I chose to take advantage of the new glibc flags like O_CLOEXEC when > they are available. This is friendlier in the Python case -- here, > gdb might have multiple threads, and the glibc flags enable us to > avoid a window where a file descriptor is not marked close-on-exec. > If the new flags or functions are not available, we fall back to > fcntl. Sorry, but I don't see the point in having #ifdef O_CLOEXEC code when there is a perfectly portable way to do this using fcntl. It leads to more bits of code that can possibly go untested. I also think it would actually be better to explicitly close file descriptors before doing an exec instead of relying on people to use the proper _cloexec call throughout gdb.