From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 3EE803857831 for ; Mon, 16 Nov 2020 01:05:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3EE803857831 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id C981B1E58F; Sun, 15 Nov 2020 20:04:59 -0500 (EST) Subject: Re: GDB 10.1: Backtrace goes into infinite loop To: psmith@gnu.org, gdb@sourceware.org References: <503bd54a619aa2781d6b1385cbd3db20634addaa.camel@gnu.org> From: Simon Marchi Message-ID: <5553a2ee-6918-87e6-2283-3cbb37b9ec6f@simark.ca> Date: Sun, 15 Nov 2020 20:04:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <503bd54a619aa2781d6b1385cbd3db20634addaa.camel@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, 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: Mon, 16 Nov 2020 01:05:01 -0000 On 2020-11-13 5:16 p.m., Paul Smith via Gdb wrote: > 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. > Hi Paul, When you see the problem happening, you could save a core file (just run the generate-core-file command). Then, try to reproduce the problem using the core file. If it reproduces, you could upload it to a bug report. Simon