bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU

[Dov Grobgeld]

So my latest investigations suggest that the problem is the "-file-list-exec-source-files" command which generates the huge output due to the large number of files that is part of the project.

The following shows the problem from the command line.

echo -file-list-exec-source-files > /tmp/gdb.in
gdb MyExec < /tmp/gdb.in > /tmp/gdb.out
wc /tmp/gdb.out
     11      69 3725105 /tmp/gdb.out

(Note that this is on a my home box, where the output is much larger than what I reported this morning possibly due to different paths).

So there are still several questions:

* Why does it take several minutes to parse a 3.7M file? Could it be related to the fact that gdb-mi/emacs concatinates the entire string before trying to parse it. Still 3.7M is far too much.

* Noted that I can't run gdb MyExec < /tmp/gdb.in in a shell buffer. It gets slower and slower while the CPU stays at 100%.

* There is a huge redundancy in gdb.out. The command -file-list-exec-source-files should output all source files included, but the same source files are listed multiple times. Consider the huge file size reduction after sorting and uniq'ing:

perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' /tmp/gdb.out | sort | uniq | wc

   3931    3931  220654

Why doesn't -file-list-exec-source file do uniq internally. This seems like a bug in gdb.

* Why does gdb-mi.el do -file-list-exec-source-files at all? Can't it search for source files on demand?

Regards,
Dov

On Tue, May 8, 2012 at 8:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Chong Yidong <cyd@gnu.org>
> Date: Wed, 09 May 2012 00:25:00 +0800
> Cc: 10580@debbugs.gnu.org

>
> Those are status messages from turning on GDB's MI (machine interface)
> system, I think, though I don't see why it makes so much difference in
> your case.
>
> If you type, from the shell,
>
>   gdb -i=mi YOUR-BINARY
>   r
>
> do you similarly see a huge output?

As you know, in addition to "run", gdb-mi.el sends lots of other
commands behind the scenes, so the above is not a faithful simulation
of what happens when GDB is run by Emacs.  But I agree that if the
above produces similarly voluminous output, we cannot really blame
gdb-mi.el.