From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 452943857025 for ; Fri, 13 Nov 2020 22:16:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 452943857025 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43004) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdhN7-0004KE-Qj for gdb@sourceware.org; Fri, 13 Nov 2020 17:16:45 -0500 Received: from pool-96-233-64-159.bstnma.fios.verizon.net ([96.233.64.159]:47236 helo=pdslaptop.home) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kdhN7-0008Sk-GC for gdb@sourceware.org; Fri, 13 Nov 2020 17:16:45 -0500 Message-ID: <503bd54a619aa2781d6b1385cbd3db20634addaa.camel@gnu.org> Subject: GDB 10.1: Backtrace goes into infinite loop From: Paul Smith Reply-To: psmith@gnu.org To: gdb@sourceware.org Date: Fri, 13 Nov 2020 17:16:44 -0500 Organization: GNU's Not UNIX! Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Fri, 13 Nov 2020 22:16:47 -0000 Hi all; I just upgraded our users from a toolset using GCC 8.1.0, binutils 2.30, and GDB 8.2.1, to a new one using GCC 10.2, binutils 2.35.1, and GDB 10.1 (on GNU/Linux x86_64). Now some of my users are running into a problem where they run the "bt" command and it shows some subset of the stack frames, then jumps back and starts over printing from frame 0, and does this forever until you use ^C to stop it. Apparently this doesn't happen every time, and the number of frames that are shown are variable (but usually a smaller number like 2 to 5 frames). By "not every time" I mean after a breakpoint sometimes we get a good bt and sometimes it recurses, but if it recurses for a given bt it will always recurse (that is if you use ^C to stop then "bt" again it recurses again). If we do the same thing with the older GDB (keeping the newer compiler/binutils) then we don't see this behavior. FWIW, the code in question is C++ code and was compiled with -ggdb3 and no optimization. Just wondering if anyone has seen something like this, and/or how to try to collect more details.