gdb 7.0.1 opening many files when breakpoints are pending

Jan Kiszka
Wed Feb 24 13:42:00 GMT 2010 wrote:
> Hi all,
> I observed gdb calling "open" many times on the same files when 
> breakpoints are still pending. About 80% of the open syscalls I traced via 
> strace go to std C headers, STL Headers and Qt Headers somewhere included 
> in the sources.
> On a normal System, this is no Problem, because the filesystem cache still 
> knows these files and delivers them immediately. On slow network file 
> systems, this becomes a problem. SMB seems to have problems with client 
> side caching contacting the server for every open, even if the same file 
> was read less then a second before, even worse when ClearCase MVFS aka 
> Dynamic Views via SMB is involved.


> Scenario;
> break main
>    <lot of code>
> break A            <-    can be resolved at start
>    <little bit of code>
> break B            <-   in a dynamically loaded .so, still pending when A 
> is reached
> gdb calls "open" 10,000 times until it reaches breakpoint A when B is not 
> set, but 600,000 times when B is set. The Project has only 6000 source 
> files and the C++ and Qt Headers are far less then 600,000. In time this 
> is one minute versus 20 minutes! until breakpoint A is reached.

Guess you should collect some more concrete stats, e.g.: How many of
those open requests are successful and not just searches? How many are
re-opening an already opened file? How many are opening a just closed
one? Or track down what happens to a concrete file that shouldn't be
opened that often.

BTW, what is the performance with this load on a standard local file system?

> Now my question:
> Why does gdb open all these files and where does it do it? The breakpoint 
> is specified as <sourcefile>:<line>, but  the debug info in the binary 
> should be sufficient to resolve the address?  I'll try to develop a path 
> if I understand why and where some of these "open" syscall can be avoided.
> looking forward to possibly speeding up debugging here,

Maybe there is actually room for optimization. But I tend to believe you
are trying to address the wrong end first. If you seriously want to
bring down your development turn-around times, get Clearcase out of the
critical path. Really. Use a native build and test environment, set up a
modern DVCS, synchronizing with the repos only when required. But this
is getting off-topic for this list.


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

More information about the Gdb mailing list