Re: GDB using a lot of CPU time and writing a lot to disk on startup

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Mon, Apr 20, 2009 at 3:40 PM, Nick Savoiu <savoiu@yahoo.com> wrote:

> I'm using GDB 6.8 (x86_64-unknown-linux-gnu) from within KDevelop
> 3.5.4. I've noticed that for some projects GDB uses 1 minute of CPU time
> and seems to do a lot of disk writing during this time.

AFAIU, GDB doesn't write anything to disk (unless you ask it to with gcore
that is).

I don't see anything in your message which would substantiate your claim
of disk writing either. How did you come to conclusion that GDB writes
anything to disk?

> ?PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
> ?3439 nsavoiu ? 16 ? 0 ?600m 589m 2536 S ? ?0 15.2 ? 1:13.64 gdb
>
> I can't really figure out why this is happening and could use some help tracking it down.
>
> 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.

It sounds like your GDB is compiled with -fomit-frame-pointers (default
on x86_64 with optimization), and pstack doesn't know how to unwind stack
for such code.

Does your inferior program (the one you are debugging) have many (as in
thousands) of shared libraries? If so, you might want to watch this thread:
http://sourceware.org/ml/gdb-patches/2009-04/msg00548.html

If not, you may want to build GDB from source with 'CFLAGS = -g -pg -O0', run
it on your inferior program, and collect the resulting profile with gprof.

-- 
Paul Pluzhnikov