From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JsctNZUjMGEJVAAAWB0awg (envelope-from ) for ; Wed, 01 Sep 2021 21:06:29 -0400 Received: by simark.ca (Postfix, from userid 112) id C84671EE22; Wed, 1 Sep 2021 21:06:29 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 0419B1ECEB for ; Wed, 1 Sep 2021 21:06:29 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 206B63854835 for ; Thu, 2 Sep 2021 01:06:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 206B63854835 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1630544788; bh=fadpAJtitsPv6vWrcMHehzpkD/Avuy5nv2tpWsBsc3o=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=YrjlCu9bxqNqj9j6vw837mN8f4el/tSRQmd6W4QuZu1qL+hPqHMMOw+k0Neni2y/a L43tM8yND9ZZBPB++t/gnr1ByvFYp74mYARzTzBIhTKrowDw98z8xulmi81N8k2Xc4 mlhkjnwzVXUvbQff6Z3RvD/STDLI4I1x5fwTc8Lo= 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: 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-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: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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