This is the mail archive of the
mailing list for the GDB project.
Re: GDB using a lot of CPU time and writing a lot to disk on startup
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?