From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3862 invoked by alias); 17 Nov 2010 10:35:23 -0000 Received: (qmail 3750 invoked by uid 22791); 17 Nov 2010 10:35:22 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nada.kth.se (HELO smtp.nada.kth.se) (130.237.222.182) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Nov 2010 10:35:16 +0000 X-Authentication-Info: The sender was authenticated as krsj using PLAIN at smtp.nada.kth.se Received: from [130.237.218.117] (dyna218-117.nada.kth.se [130.237.218.117]) (authenticated bits=0) by smtp.nada.kth.se (8.12.11.20060308/8.12.11) with ESMTP id oAHAZDiw011029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Nov 2010 11:35:13 +0100 (MET) Message-ID: <4CE3AFED.8030400@nada.kth.se> Date: Wed, 17 Nov 2010 10:35:00 -0000 From: =?UTF-8?B?S3Jpc3RvZmZlciBTasO2w7Y=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Hangs in GDB auto-complete References: <4CE279B5.5010501@nada.kth.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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: 2010-11/txt/msg00072.txt.bz2 On 2010-11-16 18:20, Tom Tromey wrote: > Kristoffer> After I upgraded my Ubuntu system to Lucid Lynx (10.04) > > What version of gdb? > gdb --version GNU gdb (GDB) 7.1-ubuntu > Kristoffer> It's very irritating, especially when I end up having to > Kristoffer> kill GDB. > > You should be able to C-c out of any completion. > If you can't, then that is a gdb bug. > Well, I can't C-c. I'm stuck in one of these right now, in fact; it's been locked up for 2-3 minutes now, at 148 % CPU according to top: 7563 krsj 20 0 184m 169m 67m R 148 8.5 5:55.72 gdb Oh, wait! My C-c went through after 2 minutes! As I said, they're not infinite lockups, but for practical purposes they may as well be sometimes. This lockup happened when I typed (gdb) p m_evaluator.m_lastWitness ...which isn't even an auto-complete, but just a symbol lookup. This particular one should work, too; it's not a typo. I'll try it again without C-c to see if it does find the symbol eventually... The executable in question is attached while running, not started by gdb, but another smaller project I am working on suffers from the same problem while being started the usual way. > Kristoffer> I've no notion of the inner workings of GDB and no idea what > Kristoffer> this is all due to, but perhaps someone here has some clue? > > We need more details, ideally enough to try to reproduce the problem. > It could be any number of things, depending on the details of what you > are doing. > I'll see if I can find some method in the madness. Pretty sure it's got nothing to do with the code I'm debugging but with my system and the way gdb is configured somehow. (I haven't deliberately modded gdb in any way, I hasten to add.) There, the print command went through finally: (gdb) p m_evaluator.m_lastWitness $111 = {point1 = {x = 0.095000000000000001, y = 0.044999999999999998, z = 1}, point2 = {x = 0.095000000000000001, y = 0.044999999999999998, z = 1.2599999713897705}, distance = 0.25999997138977049, typeOnA = spatial::WITNESS_FACE, typeOnB = spatial::WITNESS_VERTEX, idOnA = 0, idOnB = 4, paramOnA = 0, paramOnB = 7.5651897269402635e-306, normal = {x = 0, y = 0, z = 1}} I sure would like to be able to query variables reliably in less than three minutes, though... I'll see what I can do about setting up a repro case. Kristoffer