From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 1FA443858412 for ; Thu, 2 Sep 2021 01:05:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1FA443858412 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 18215akQ025578 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Sep 2021 21:05:41 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 18215akQ025578 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 8BF791ECEB; Wed, 1 Sep 2021 21:05:36 -0400 (EDT) Subject: Re: GDB abort on glibc detected file descriptor overflow To: "Ananthakrishna Sowda (asowda)" , "gdb@sourceware.org" References: From: Simon Marchi Message-ID: Date: Wed, 1 Sep 2021 21:05:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 2 Sep 2021 01:05:36 +0000 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 01:05:54 -0000 On 2021-09-01 6:37 p.m., Ananthakrishna Sowda (asowda) via Gdb wrote: > I’m observing abort in GDB 9.2.1 version, and same issue is present in git://sourceware.org/git/binutils-gdb.git tip. > > The full call trace is shown at the end of this message. > In frame 7, call to FD_SET is causing buffer overflow when commands from a GDB macro file are processed. > > (gdb) frame 7 > #7 0x000000000076978b in gdb_readline_no_editing (prompt=) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/top.c:850 > 850 FD_SET (fd, &readfds); > (gdb) p fd > $1 = 1533 > > GDB is processing split dwarf “.dwp” file for the main executable and processing some “.dwo” files in the workspace, which may have something to do with it. GDB is opening a bunch of .debug files , one each for every library and the open file descriptors go past 1024. This results in buffer overflow when gdb.macros file is opened and processed in frame 7 ( file descriptor 1533). > > The bfd file descriptor caching code which tries to limit no of open descriptors is not effective in this case. > Does this explanation make sense? Any ideas to fix this issue are greatly appreciated. It won't fix the problem, but I think we could start by adding an assertion before calling FD_SET (everywhere where we do call it): gdb_assert (fd < FD_SETSIZE); Your build happened to catch it, but other builds could just fail silently or crash in less clear ways. As for the solution, maybe this code should be converted to use poll or other more modern APIs to avoid this limit? It would be interesting if you could show what are the open file descriptors at this point (list /proc//fd), just to see what uses the most fds. Simon