More tests.

1. I was mistaken in my previous email, the CPU spending was triggered
before gdb-mode-hook.
2. The following command in gdb-input starts the 40s 100% CPU:

  (process-send-string (get-buffer-process gud-comint-buffer)
               (concat command "\n")))

where command="1-inferior-tty-set /dev/pts/9". Note that the command
returns immediately, but some other thread apparently gets very busy.

Is this enough info, or do you want me to probe deeper?

On Wed, Jan 25, 2012 at 10:49, Dov Grobgeld <dov.grobgeld@gmail.com> wrote:

> Here are some more tests:
>
> 1. It doesn't get stuck when debugging a "hello-world.c" program. Thus it
> depends on the executable.
> 2. Regarding toggle-debug-on-quit and C-g, it doesn't work. No backtrace
> is produced and the CPU continues to be at 100%.
> 3. I tried running edebug on gdb, which wasn't easy. I had to manually
> first do eval-buffer on gdb-mi.el and gud.el. But in the end I managed and
> found that the CPU is spend during (run-hooks 'gdb-mode-hook) . I'll try to
> investigate it further in the next few days.
>
> Regards,
> Dov
>
> On Wed, Jan 25, 2012 at 02:37, Glenn Morris <rgm@gnu.org> wrote:
>
>>
>> >> I tried again with emacs -Q and the same thing happens. To be more
>> >> precise the startup time is about 40s at 100% CPU.
>>
>> Is this with everything you try to debug, or just certain things?
>>
>> Can you try M-x toggle-debug-on-quit, then interrupt Emacs with ctrl-g
>> during those 40 seconds and see if you get a backtrace?
>>
>> Or try M-x edebug-defun on the `gdb' function, step through it, and see
>> what is taking the time.
>>
>> Guesses: do you have a huge .gdb_history or ~/.gdbinit file?
>>
>
>