From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id TuUQM9EFr19IAgAAWB0awg (envelope-from ) for ; Fri, 13 Nov 2020 17:16:49 -0500 Received: by simark.ca (Postfix, from userid 112) id C42491F08B; Fri, 13 Nov 2020 17:16:49 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.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 C14D21E58D for ; Fri, 13 Nov 2020 17:16:48 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0885F3951868; Fri, 13 Nov 2020 22:16:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0885F3951868 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605305808; bh=L/6iWI5hrHCPd5z8mHyuCYDJJKbcMvfgOyTzXqMMHYE=; h=Subject:To:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=rYtnlP8huW8zyv607WaBTVAJT4+DMF4ebo5Ngrm8IDB2Tl5EsON+hE97QbFPExDxc g2L2XzbITyto6mHXMeGLA8XEIrVoCwbprLr0BPDA/4nq0wFC2/M6LD8QacDy9A7Mc+ 82g7+AcC9fC0vr/vzbkILKpSFpjlcZWX510Z76Po= 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 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-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: Paul Smith via Gdb Reply-To: psmith@gnu.org Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" 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.