gdb eats 100% cpu for relative long time when I single step one instruction

gdb eats 100% cpu for relative long time when I single step one instruction

[Thomas Glanzmann]

Hello,
I tried to debug an opera binary without debugging information and did
the following:

gdb ./opera
	b *0x0838FF00
	layout asm
	layout regs
	run 2> /dev/null

When I hit the breakpoint gdb starts eating my CPU. I have Athlon XP
1700 running Linux 2.6 Debian Sarge. After I get the gdb prompt back I
type ni to singlestep to 'push %ebp' which takes a few seconds. I
started top and saw that gdb eats my cpu. My X is nearly freezed and I
also have trouble to change windows between windows in remote and local
screen sessions.

Whatever my guess is that gdb does some data analyzing it takes very
long because the binary is compiled without debugging information. Is
there a switch that I can turn this off or how can I check what gdb does
while it blocks my machine during the single step?

This happens *only* when I call 'layout asm' gdb thinks that I am in the
function jzero_far which is at 0x81cd12a but I am actually in a funtion
without a debugging symbol at 0x838fdcb, so I think the 'layout regs'
tries to analyse this few thousand instructions or whatever. Is there a
way to tell 'layout regs' to show only the few surrounding instructions?

	Thomas

Re: gdb eats 100% cpu for relative long time when I single step one instruction

[Daniel Jacobowitz]

On Mon, Jun 27, 2005 at 11:27:04PM +0200, Thomas Glanzmann wrote:
> This happens *only* when I call 'layout asm' gdb thinks that I am in the
> function jzero_far which is at 0x81cd12a but I am actually in a funtion
> without a debugging symbol at 0x838fdcb, so I think the 'layout regs'
> tries to analyse this few thousand instructions or whatever. Is there a
> way to tell 'layout regs' to show only the few surrounding instructions?

These are just display panes.  It sounds like something is broken
inside the TUI.  You'll have to build a debuggable GDB and attach
another gdb to it to see what it's spinning on.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdb eats 100% cpu for relative long time when I single step one instruction

[Thomas Glanzmann]

Hello,

> These are just display panes.  It sounds like something is broken
> inside the TUI.  You'll have to build a debuggable GDB and attach
> another gdb to it to see what it's spinning on.

I made a screenshot[1]. I guess that every time I do a single step gdb
tries to analyze the jzero_far function he thinks I am in. He also says 
jzero_far+1846439. But if this doesn't help I can attach.

I executed 'ni' in the gdb window and attached

	strace -o dbg -fp `pidof gdb`

And he does:

(excalibur) [~] cat dbg
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0x8249d14, [0x49e94050]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0xb7fd0ce0, [0xb74400c0]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0x8249d14, [0x49e94050]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0x8249d18, [0x90fffffd]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0xb7fd0ce0, [0xb74400c0]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0x8249d18, [0x90fffffd]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0xb7fd0ce0, [0xb74400c0]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0x8249d1c, [0xff08458b]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0xb7fd0ce0, [0xb74400c0]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0x8249d1c, [0xff08458b]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0xb7fd0ce0, [0xb74400c0]) = 0
1317  ptrace(PTRACE_PEEKTEXT, 1318, 0x8249d1c, [0xff08458b]) = 0
...

(excalibur) [~] wc -l dbg
1728579 dbg

And I started the ptrace *after* I typed 'ni' in and interrupted it before 'ni'
came back:

	Thomas

[1] gdb screenshot
	http://wwwcip.informatik.uni-erlangen.de/~sithglan/shot1.png

Re: gdb eats 100% cpu for relative long time when I single step one instruction

[Daniel Jacobowitz]

On Mon, Jun 27, 2005 at 11:59:15PM +0200, Thomas Glanzmann wrote:
> Hello,
> 
> > These are just display panes.  It sounds like something is broken
> > inside the TUI.  You'll have to build a debuggable GDB and attach
> > another gdb to it to see what it's spinning on.
> 
> I made a screenshot[1]. I guess that every time I do a single step gdb
> tries to analyze the jzero_far function he thinks I am in. He also says 
> jzero_far+1846439. But if this doesn't help I can attach.

Sorry, this doesn't tell me much.  I'd need backtraces inside GDB to
know what it thinks it is doing.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdb eats 100% cpu for relative long time when I single step one instruction

[Thomas Glanzmann]

Hello,

> Sorry, this doesn't tell me much.  I'd need backtraces inside GDB to
> know what it thinks it is doing.

Okay. I will recompile gdb tomorrow with debugging symbols and provide a
backtrace. Anything I should obey?

	Thomas

Re: gdb eats 100% cpu for relative long time when I single step one instruction

[Thomas Glanzmann]

Hello,
I compiled gdb with profiling and did my workload:

	Each sample counts as 0.01 seconds.
	  %   cumulative   self              self     total
	 time   seconds   seconds    calls   s/call   s/call  name
	 64.71    127.12   127.12  2169997     0.00     0.00  lookup_minimal_symbol_by_pc_section
	  2.42    131.88     4.76                             print_insn
	  1.95    135.71     3.83   723364     0.00     0.00  find_pc_sect_psymtab
	  1.72    139.09     3.39   723354     0.00     0.00  find_pc_sect_symtab
	  1.68    142.40     3.31  6052249     0.00     0.00  tui_file_adjust_strbuf
	  1.28    144.92     2.52  2170204     0.00     0.00  find_pc_sect_section
	  1.08    147.03     2.12  6052860     0.00     0.00  tui_file_fputs
	  1.04    149.07     2.04 21819200     0.00     0.00  xmalloc

and this is the backtrace:

	(gdb) bt
	#0  0x080f12f2 in find_pc_sect_psymtab ()
	#1  0x080f2597 in find_pc_sect_symtab ()
	#2  0x080f0545 in blockvector_for_pc_sect ()
	#3  0x080f0624 in block_for_pc_sect ()
	#4  0x080ce0e1 in find_pc_sect_function ()
	#5  0x080ee196 in build_address_symbolic ()
	#6  0x080ee028 in print_address_symbolic ()
	#7  0x080ee3b3 in print_address ()
	#8  0x080bfe66 in tui_disassemble ()
	#9  0x080bffe7 in tui_find_disassembly_address ()
	#10 0x080c04be in tui_get_low_disassembly_address ()
	#11 0x080c553a in tui_show_frame_info ()
	#12 0x080c157f in tui_selected_frame_level_changed_hook ()
	#13 0x0808abed in select_frame ()
	#14 0x08103fd2 in normal_stop ()
	#15 0x08101b3b in proceed ()
	#16 0x080ff125 in step_1 ()
	#17 0x080fef27 in nexti_command ()
	#18 0x080b3812 in do_cfunc ()
	#19 0x080b5709 in cmd_func ()
	#20 0x08083ec5 in execute_command ()
	#21 0x0810eb5b in command_handler ()
	#22 0x0810f1c6 in command_line_handler ()
	#23 0x082021e0 in rl_callback_read_char () at callback.c:123
	#24 0x0810e420 in rl_callback_read_char_wrapper ()
	#25 0x0810ea18 in stdin_event_handler ()
	#26 0x0810dd60 in handle_file_event ()
	#27 0x0810d7e7 in process_event ()
	#28 0x0810d838 in gdb_do_one_event ()
	#29 0x08083b41 in do_catch_errors ()
	#30 0x08083936 in catcher ()
	#31 0x08083b9c in catch_errors ()
	#32 0x080c190e in tui_command_loop ()
	#33 0x0810b6bc in current_interp_command_loop ()
	#34 0x0807b44c in captured_command_loop ()
	#35 0x08083b41 in do_catch_errors ()
	#36 0x08083936 in catcher ()
	#37 0x08083b9c in catch_errors ()
	#38 0x0807c1ec in captured_main ()
	#39 0x08083b41 in do_catch_errors ()
	#40 0x08083936 in catcher ()
	#41 0x08083b9c in catch_errors ()
	#42 0x0807c224 in gdb_main ()
	#43 0x0807b437 in main ()

Greetings,
	Thomas

Re: gdb eats 100% cpu for relative long time when I single step one instruction

[Daniel Jacobowitz]

On Tue, Jun 28, 2005 at 02:26:59PM +0200, Thomas Glanzmann wrote:
> Hello,
> I compiled gdb with profiling and did my workload:
> 
> 	Each sample counts as 0.01 seconds.
> 	  %   cumulative   self              self     total
> 	 time   seconds   seconds    calls   s/call   s/call  name
> 	 64.71    127.12   127.12  2169997     0.00     0.00  lookup_minimal_symbol_by_pc_section
> 	  2.42    131.88     4.76                             print_insn
> 	  1.95    135.71     3.83   723364     0.00     0.00  find_pc_sect_psymtab
> 	  1.72    139.09     3.39   723354     0.00     0.00  find_pc_sect_symtab
> 	  1.68    142.40     3.31  6052249     0.00     0.00  tui_file_adjust_strbuf
> 	  1.28    144.92     2.52  2170204     0.00     0.00  find_pc_sect_section
> 	  1.08    147.03     2.12  6052860     0.00     0.00  tui_file_fputs
> 	  1.04    149.07     2.04 21819200     0.00     0.00  xmalloc
> 
> and this is the backtrace:
> 
> 	(gdb) bt
> 	#0  0x080f12f2 in find_pc_sect_psymtab ()
> 	#1  0x080f2597 in find_pc_sect_symtab ()
> 	#2  0x080f0545 in blockvector_for_pc_sect ()
> 	#3  0x080f0624 in block_for_pc_sect ()
> 	#4  0x080ce0e1 in find_pc_sect_function ()
> 	#5  0x080ee196 in build_address_symbolic ()
> 	#6  0x080ee028 in print_address_symbolic ()
> 	#7  0x080ee3b3 in print_address ()
> 	#8  0x080bfe66 in tui_disassemble ()
> 	#9  0x080bffe7 in tui_find_disassembly_address ()
> 	#10 0x080c04be in tui_get_low_disassembly_address ()

Jason sent me a hint offlist and this confirms it.  Because GDB can't
find a symbol, it's going all the way back to the nearest symbol it CAN
find, and disassembling forwards until it reaches this spot.  It's
disassembling an awful lot of lines.  This is specific to the TUI.

It could be made less completely dog-slow by using a different function
when searching, since print_address is what's really hurting you.  It'd
still be pretty inefficient, but getting this right on x86 is tricky.

Take a look at tui_find_disassembly_address.


-- 
Daniel Jacobowitz
CodeSourcery, LLC