From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27553 invoked by alias); 6 Nov 2014 10:50:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 27531 invoked by uid 89); 6 Nov 2014 10:50:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 06 Nov 2014 10:50:56 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA6AotWi024532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 6 Nov 2014 05:50:55 -0500 Received: from blade.nx (ovpn-116-104.ams2.redhat.com [10.36.116.104]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA6Aosff004632 for ; Thu, 6 Nov 2014 05:50:55 -0500 Received: from blade.nx (localhost [127.0.0.1]) by blade.nx (Postfix) with ESMTP id E3F36262698 for ; Thu, 6 Nov 2014 10:50:53 +0000 (GMT) From: Gary Benson To: gdb-patches@sourceware.org Subject: [PATCH 0/3 v2] Limit tab-completion result when list is large Date: Thu, 06 Nov 2014 10:50:00 -0000 Message-Id: <1415271046-4957-1-git-send-email-gbenson@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00113.txt.bz2 Hi all, When debugging large programs, pressing the Tab key at the wrong time causes GDB to lock up while it builds a completion list. As an example, with LibreOffice: $ gdb /usr/lib64/libreoffice/program/soffice.bin (gdb) start (gdb) b On my (pretty fast!) machine the user is left hanging for nearly a minute while GDB builds a list of the 212405 places the user could break on. This is PR cli/11920. PR cli/15548 proposes to abort building the completion list if it grows too large, the theory being that nobody is going to scroll through thousands of screens of completions to find the one they want. These three patches implement this. The default limit is 200 completions, which the user can override with a new set/show option. Tested on RHEL6.5 x86_64, no regressions. Is this ok to commit? Thanks, Gary -- http://gbenson.net/