From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2554 invoked by alias); 2 Sep 2009 03:42:11 -0000 Received: (qmail 2545 invoked by uid 22791); 2 Sep 2009 03:42:10 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Sep 2009 03:42:05 +0000 Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id n823g2M3030297 for ; Tue, 1 Sep 2009 20:42:02 -0700 Received: from an-out-0708.google.com (ancc5.prod.google.com [10.100.29.5]) by wpaz33.hot.corp.google.com with ESMTP id n823fZjT005185 for ; Tue, 1 Sep 2009 20:42:00 -0700 Received: by an-out-0708.google.com with SMTP id c5so232186anc.10 for ; Tue, 01 Sep 2009 20:41:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.65.19 with SMTP id s19mr8716699ank.3.1251862919846; Tue, 01 Sep 2009 20:41:59 -0700 (PDT) In-Reply-To: <20090901204815.GK4379@adacore.com> References: <20090901204815.GK4379@adacore.com> Date: Wed, 02 Sep 2009 03:42:00 -0000 Message-ID: <8ac60eac0909012041i1a9d4f8fmbd13d19ec8039ef0@mail.gmail.com> Subject: Re: More info on PR/9711 (quadratic slowdown for deep stack traces) From: Paul Pluzhnikov To: Joel Brobecker Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00011.txt.bz2 On Tue, Sep 1, 2009 at 1:48 PM, Joel Brobecker wrote: > Taking a step back, it does not feel like this is actually a super > common issue. For this to happen, we need a program such that we get > a really deep stack (with 1000 iterations, it takes 1.5 secs before > my change, about 0.5 sec after IIRC), and a register that does not > get saved throughout the entire stack. Since we still end up printing > the correct value at the end, is it worth enhancing the design to > handle this case? It's been almost a year since I filed this PR, so am hazy on details :-( AFAIR, the real problem showed up while debugging GDB itself, when I made it go into infinite recursion loop. Making programs spin into the ground via infinite recursion is not that uncommon (IMHO) and when that happens, you do get 100_000 or more frames, and usually you only care about the outermost 10 of so. It is quite annoying if GDB takes several minutes to tell you what these 10 interesting frames are. Cheers, -- Paul Pluzhnikov