[Bug gdb/17764] Excessive seeking when reading debug data pegs the CPU @100%

["mrsam at courier-mta dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17764

--- Comment #3 from Sam Varshavchik <mrsam@courier-mta.com> ---
The .so's total size is 60 megabytes. readelf shows all the debug data starting
at about the 14 megabyte mark, so, say around 46 megs of debug data, give or
take a meg.

I monitored the virtual memory size of the gdb process itself, while it was
spinning. gdb was not allocating an appreciable amount of memory.

gdb-add-index grew the .so to 70 megs in size, but made no visible difference
-- gdb still pegged the CPU for over a minute at startup.

One thing I've noticed is that gdb seems to be rereading the same debug data
over and over again.

If I grep just the seek offsets, the remove the consecutive dupes only, then
sort the deduped list again, I still find that the gdb process often re-seeks
back to the same offset, something like this:

grep lseek | awk ' { print $2 } ' | uniq | sort | uniq -c

Partial results from this:

    926 8769536,
    926 8773632,
    926 8777728,
    925 8781824,
    888 8785920,
    632 8790016,
    376 8794112,
    120 8798208,

So, it seems like after reading from seek offset 8769536, for example, the gdb
process then seeked somewhere else, but at some point went back and reread it
again. Almost a thousand times. This is with the gdb-add-index data in the .so;
but, again, that took about the same amount of time as without it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.