From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12065 invoked by alias); 9 Nov 2011 18:47:47 -0000 Received: (qmail 12038 invoked by uid 22791); 9 Nov 2011 18:47:45 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_OC X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Nov 2011 18:47:31 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 478162BB110; Wed, 9 Nov 2011 13:47:30 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id I3+QN+wdj0Cp; Wed, 9 Nov 2011 13:47:30 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 17C3E2BB0FC; Wed, 9 Nov 2011 13:47:30 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id C3C5A145615; Wed, 9 Nov 2011 13:47:20 -0500 (EST) From: Joel Brobecker To: gdb-patches@sourceware.org Cc: Joel Brobecker Subject: [RFA/commit/procfs] /proc/.../map file descriptor leak Date: Wed, 09 Nov 2011 18:47:00 -0000 Message-Id: <1320864439-12456-1-git-send-email-brobecker@adacore.com> 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: 2011-11/txt/msg00251.txt.bz2 Hello, This is on sparc-solaris. I was trying to reproduce another error that our testsuite occasionally reports (without much success :-(). I noticed while running the test repeatedly within the same debugger process (that is: repeatedly doing "run; [...]; kill" instead of starting a new debugger every time) that it would eventually cause another error in the debugger. The debugger would be telling us that it is unable to find a given thread in the procinfo list. In other words, the debugger received an event for LWP=1 and then failed to create the assocated thread element in the procinfo list. After some investgation, it turned out that this was because we were unable to open the associated lwp file in the /proc filesystem, and that was because we ran out of file descriptors! Digging further, I found that we leak the file descriptor created when opening the procfs map file. we create a cleanup routine to make sure that the associated file descriptor gets closed, but we never call the cleanup. gdb/ChangeLog: * procfs.c (iterate_over_mappings): Call do_cleanups before returning. Fixed thusly. Seems fairly straightforward, except that the cleanup is only really needed when NEW_PROC_API is defined (basically, Solaris except old versions). But I think that #ifdef code is ugly, so I made the cleanup run regardless... I'll commit in a couple of days pending feedback... --- gdb/procfs.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/gdb/procfs.c b/gdb/procfs.c index 871dd47..2a253a1 100644 --- a/gdb/procfs.c +++ b/gdb/procfs.c @@ -5217,6 +5217,7 @@ iterate_over_mappings (procinfo *pi, find_memory_region_ftype child_func, int funcstat; int map_fd; int nmap; + struct cleanup *cleanups = make_cleanup (null_cleanup, NULL); #ifdef NEW_PROC_API struct stat sbuf; #endif @@ -5254,8 +5255,12 @@ iterate_over_mappings (procinfo *pi, find_memory_region_ftype child_func, for (prmap = prmaps; nmap > 0; prmap++, nmap--) if ((funcstat = (*func) (prmap, child_func, data)) != 0) - return funcstat; + { + do_cleanups (cleanups); + return funcstat; + } + do_cleanups (cleanups); return 0; } -- 1.7.1