Fw: Antwort: Re: [REASON FOUND] Re: gdb 7.0.1 opening many files when breakpoints are pending

[Martin dot Runge at rohde-schwarz dot com]

Hi all, Tom,

Problem seems to be that gdb searches all source files mentioned in the 
symtabs just to find the on from the break command. For setting the 
berakpoint, gdb needs the symtab of that source file. Unfortunately, gdb 
calls 'stat' and 'open' on the other source files, too. But why?

The test program, filename was main.cpp (all below done with gdb-7.1):

#include <iostream>
#include <string>

using namespace std;

int main( int argc, char *argv[] )
{
  string mystr("Hallo");
  cerr << mystr << endl;                      # line 9, breakpoint here
  return 0;
}

here is a strace when setting a breakpoint via abulute source path:

(gdb) break /home/RSINT/runge_m/devel/gdb-test/whyopen/src/main.cpp:9
open("/usr/include/c++/4.2/iostream", O_RDONLY|O_LARGEFILE) = 8
open("/usr/include/c++/4.2/iostream", O_RDONLY|O_LARGEFILE) = 8
open("/usr/include/c++/4.2/bits/locale_facets.tcc", O_RDONLY|O_LARGEFILE) 
= 8
open("/usr/include/c++/4.2/bits/locale_facets.tcc", O_RDONLY|O_LARGEFILE) 
= 8
open("/usr/include/c++/4.2/bits/stl_algobase.h", O_RDONLY|O_LARGEFILE) = 8
open("/usr/include/c++/4.2/bits/stl_algobase.h", O_RDONLY|O_LARGEFILE) = 8
open("/home/RSINT/runge_m/devel/gdb-test/whyopen/build/whyopen", 
O_RDONLY|O_LARGEFILE) = 8
open("/home/RSINT/runge_m/devel/gdb-test/whyopen/src/main.cpp", 
O_RDONLY|O_LARGEFILE) = 9
open("/home/RSINT/runge_m/devel/gdb-test/whyopen/src/main.cpp", 
O_RDONLY|O_LARGEFILE) = 9
Breakpoint 1 at 0x8048a32: file 
/home/RSINT/runge_m/devel/gdb-test/whyopen/src/main.cpp, line 9.

Here is the backtrace of a catchpoint ( catch syscall open ) when iostream 
was opened:

Catchpoint 3 (call to syscall 'open'), 0x002da402 in __kernel_vsyscall ()
(top-gdb) bt
#0  0x002da402 in __kernel_vsyscall ()
#1  0x007c9bf2 in open64 () from /lib/tls/i686/cmov/libc.so.6 
#2  0x081361f6 in openp (path="/usr/include/c++/4.2/iostream", mode=<value 
optimized out>, filename_opened=0x97a9a08) at source.c:738
#3  0x081363c6 in find_and_open_source (filename=0x9796ec0 
"/usr/include/c++/4.2/iostream", dirname=0x0, fullname=0x97a9a08) at 
source.c:1044
#4  0x081364f4 in psymtab_to_fullname (ps=0x97a9a00) at source.c:1115
#5  0x081587fc in lookup_partial_symtab (name=0xbff48090 
"/home/RSINT/runge_m/devel/gdb-test/whyopen/src/main.cpp") at symtab.c:285
#6  0x08158aac in lookup_symtab (name=0xbff48090 
"/home/RSINT/runge_m/devel/gdb-test/whyopen/src/main.cpp") at symtab.c:228
#7  0x08162000 in symtab_from_filename (argptr=0xbff48344, p=0x96cf3cd 
":9", is_quote_enclosed=0, not_found_ptr=0xbff483bc) at linespec.c:1586
#8  0x08162cbf in decode_line_1 (argptr=0xbff48344, funfirstline=1, 
default_symtab=0x0, default_line=0, canonical=0xbff483c0, 
not_found_ptr=0xbff483bc) at linespec.c:783
#9  0x08124ecd in parse_breakpoint_sals (ui=0x9771ba0, data=0xbff48390) at 
breakpoint.c:6585
#10 do_captured_parse_breakpoint (ui=0x9771ba0, data=0xbff48390) at 
breakpoint.c:6653
#11 0x0817b092 in catch_exception (uiout=0x9771ba0, func=0x8124c70 
<do_captured_parse_breakpoint>, func_args=0xbff48390, mask=6) at 
exceptions.c:462
#12 0x08128709 in break_command_really (gdbarch=0x9769e08, arg=0x96cf396 
"/home/RSINT/runge_m/devel/gdb-test/whyopen/src/main.cpp:9", 
cond_string=0x8000 <Address 0x8000 out of bounds>, thread=0, 
parse_condition_and_thread=1, tempflag=0, hardwareflag=0, traceflag=0, 
ignore_count=0, pending_break_support=AUTO_BOOLEAN_TRUE, ops=0x0, 
from_tty=1, enabled=1) at breakpoint.c:6770
#13 0x08129472 in break_command_1 (arg=0x96cf396 
"/home/RSINT/runge_m/devel/gdb-test/whyopen/src/main.cpp:9", flag=0, 
from_tty=1) at breakpoint.c:6942
#14 0x0809a3f1 in execute_command (p=0x96cf3ce "9", from_tty=1) at 
top.c:441
#15 0x08180968 in command_handler (command=0x96cf390 "break 
/home/RSINT/runge_m/devel/gdb-test/whyopen/src/main.cpp:9") at 
event-top.c:511
#16 0x081815e3 in command_line_handler (rl=0x97951f0 "break 
/home/RSINT/runge_m/devel/gdb-test/whyopen/src/main.cpp:9") at 
event-top.c:736
#17 0x082467ef in rl_callback_read_char () at callback.c:205
#18 0x08180aab in rl_callback_read_char_wrapper (client_data=0x0) at 
event-top.c:178
#19 0x081805ce in handle_file_event (data=...) at event-loop.c:811
#20 0x0817f89c in process_event () at event-loop.c:393
#21 0x08180512 in gdb_do_one_event (data=0x0) at event-loop.c:458
#22 0x0817ae83 in catch_errors (func=0x8180330 <gdb_do_one_event>, 
func_args=0x0, errstring=0x82e4c72 "", mask=6) at exceptions.c:510
#23 0x081030a4 in tui_command_loop (data=0x0) at ./tui/tui-interp.c:154
#24 0x0817b4bf in current_interp_command_loop () at interps.c:291
#25 0x0809198b in captured_command_loop (data=0x0) at ./main.c:226
#26 0x0817ae83 in catch_errors (func=0x8091980 <captured_command_loop>, 
func_args=0x0, errstring=0x82e4c72 "", mask=6) at exceptions.c:510
#27 0x08090fd6 in captured_main (data=0xbff48734) at ./main.c:905
#28 0x0817ae83 in catch_errors (func=0x80908a0 <captured_main>, 
func_args=0xbff48734, errstring=0x82e4c72 "", mask=6) at exceptions.c:510
#29 0x08090671 in gdb_main (args=0xbff48734) at ./main.c:914
#30 0x08090635 in main (argc=Cannot access memory at address 0x8000) at 
gdb.c:33


to set the breakpoint (get its address) from the source location, gdb 
searches all source files entries in the symbol tables for a matching 
file. When the breakpoint was set without path ( filename:Nr ), there is 
no other way than taking the first filename found in the symtab with a 
matching name, ignoring the path (called tail matching in the sources). 
This could possibly lead to wrong breakpoint location when several 
sourcefiles with the same name were used, so.
When breakpoint is set with absolute path, gdb tries to be more precise. 
It checks if a source file mentioned in the symbol table exists at the 
given location with path substitution applied (set substitute-path from 
to). But this is done by using a search path, usually including $cdir and 
$cwd, that is why gdb tries to stat and open that file to know with on 
which of these search pathes the file was found. If found, the symtab the 
source filename was taken from is used to compute the address.

Would it be enough to check if breakpoint path and symtab path with 
substitution applied match? No file opening would be needed then. 

I attached a small patch that skips files that do not tail match from 
further search, avoiding the first six open from the strace above. Please 
let me know what you think about it.

best regards 
Martin










Tom Tromey <tromey@redhat.com> 
Gesendet von: gdb-owner@sourceware.org
03.03.2010 23:16
Bitte antworten an
tromey@redhat.com


An
Martin.Runge@rohde-schwarz.com
Kopie
gdb@sourceware.org
Thema
Re: [REASON FOUND] Re: gdb 7.0.1 opening many files when breakpoints are 
pending






>>>>> "Martin" == Martin Runge <Martin.Runge@rohde-schwarz.com> writes:

Martin> These are already eight calls to "open" for setting a single
Martin> breakppoint in a three line program. When dynamically loaded .so
Martin> are involved, this happens every time gdb stops in the dynamic
Martin> linker trying to set the pending breakpoints. This is where the
Martin> ridiculous number of 600.000 opens comes from.

It would be good to see a stack trace starting from one of these calls
to open.

Martin> Why are these header files opened? Is there a good reason for it
Martin> or can this possibly be optimized?

I don't know; I ran across this today and wondered if it is related:

    http://sourceware.org/bugzilla/show_bug.cgi?id=10261

Tom

Attachment: dont_open_headers_on_set_breakpoint.patch
Description: Binary data