From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4291 invoked by alias); 20 Apr 2009 23:48:15 -0000 Received: (qmail 4272 invoked by uid 22791); 20 Apr 2009 23:48:14 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Apr 2009 23:48:09 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D32E910A05; Mon, 20 Apr 2009 23:48:06 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 9E0AC1018E; Mon, 20 Apr 2009 23:48:06 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1Lw3DZ-0007Vi-D2; Mon, 20 Apr 2009 19:48:05 -0400 Date: Mon, 20 Apr 2009 23:55:00 -0000 From: Daniel Jacobowitz To: Paul Pluzhnikov Cc: Nick Savoiu , gdb@sourceware.org Subject: Re: GDB using a lot of CPU time and writing a lot to disk on startup Message-ID: <20090420234805.GA28850@caradoc.them.org> Mail-Followup-To: Paul Pluzhnikov , Nick Savoiu , gdb@sourceware.org References: <592922.54823.qm@web52001.mail.re2.yahoo.com> <8ac60eac0904201639r19f7d539v2b301fcb24e82317@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8ac60eac0904201639r19f7d539v2b301fcb24e82317@mail.gmail.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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-04/txt/msg00163.txt.bz2 On Mon, Apr 20, 2009 at 04:39:56PM -0700, Paul Pluzhnikov wrote: > > I used pstack every second until the debugging actually starts and here > > are all the unique #0 locations in the pstack output. > > > > #0  0x0000000000446d16 in msymbol_hash_iw () > > #0  0x0000000000446f97 in lookup_minimal_symbol () > > #0  0x00000000004bfda0 in symbol_natural_name () > > #0  0x00000000004bffe4 in find_pc_sect_psymtab () > > #0  0x00000000004c0118 in find_pc_sect_psymbol () > > #0  0x00000000004fd755 in bcache_data () > > #0  0x000000000050d11a in dwarf2_lookup_abbrev () > > #0  0x0000000000610c67 in d_print_comp () > > #0  0x00000035aae28250 in __ctype_b_loc () from /lib64/tls/libc.so.6 > > #0  0x00000035aae68ced in _int_free () from /lib64/tls/libc.so.6 > > #0  0x00000035aaeb94a5 in _xstat () from /lib64/tls/libc.so.6 > > #0  0x00000035aaeb9545 in _lxstat () from /lib64/tls/libc.so.6 > > #0  0x00000035aaeb9832 in __open_nocancel () from /lib64/tls/libc.so.6 > > #0  0x00000035aaebe18f in poll () from /lib64/tls/libc.so.6 > > This output is bogus. I thought that too the first time I read it - but see his description of the output (above) again :-) Nick, it sounds to me like you're debugging something that you haven't got enough RAM for - is the disk I/O your swap space? -- Daniel Jacobowitz CodeSourcery