From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13679 invoked by alias); 16 Jan 2009 05:48:17 -0000 Received: (qmail 13670 invoked by uid 22791); 16 Jan 2009 05:48:17 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_36,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; Fri, 16 Jan 2009 05:47:41 +0000 Received: from spaceape14.eur.corp.google.com (spaceape14.eur.corp.google.com [172.28.16.148]) by smtp-out.google.com with ESMTP id n0G5lcWX028727 for ; Thu, 15 Jan 2009 21:47:38 -0800 Received: from wf-out-1314.google.com (wff28.prod.google.com [10.142.6.28]) by spaceape14.eur.corp.google.com with ESMTP id n0G5khiM031990 for ; Thu, 15 Jan 2009 21:47:35 -0800 Received: by wf-out-1314.google.com with SMTP id 28so1700039wff.30 for ; Thu, 15 Jan 2009 21:47:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.90.16 with SMTP id n16mr861685wfb.314.1232084854535; Thu, 15 Jan 2009 21:47:34 -0800 (PST) In-Reply-To: <20090116034623.GJ31296@adacore.com> References: <20090115034552.GF24105@adacore.com> <20090116034623.GJ31296@adacore.com> Date: Fri, 16 Jan 2009 05:48:00 -0000 Message-ID: <8ac60eac0901152147o75f189bdm42053173bb29d5b9@mail.gmail.com> Subject: Re: Discussing the next GDB release (GDB 7.0?) From: Paul Pluzhnikov To: Joel Brobecker Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-01/txt/msg00088.txt.bz2 On Thu, Jan 15, 2009 at 7:46 PM, Joel Brobecker wrote: >> Anything else that you'd like to be put on the list for >> this release? > > Tom suggested PR/9711: Quadratic slowdown in backtrace command. > I added to the list because it is a regression compared to 6.8, > but the example given shows the heavy slowdown only with a very > large number of frames. I wonder if this can happen with a more > typical number of frames - I suspect that Paul (the submitter) > probably hit the problem in a real situation before coming up > with this reduced example... Correct. It happened while debugging gdb+python on archer branch, which I accidentally put into an infinite recursion. This had quite a large number of frames, *and* there were more parameters in each frame, so it took longer. IIRC, it took about 15 minutes to get to the top of the stack, where the "interesting" frames were. I don't believe putting a program into infinite recursion is very unusual; I've done it many times in the past :-( And when that does happen, waiting minutes for GDB to unwind stack is the last thing you want to do. -- Paul Pluzhnikov