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

From: Dov Grobgeld <[email-masked]>
Date: Mon, 30 Apr 2012 09:36:40 +0300

Here is some more clarification. In keyboard.c:command_loop_1() the
line i=read_key_sequence() blocks during interactive work until a key
is pressed. But when the process is stuck in "gdb" read_key_sequence()
does not block but keeps returning. I still have no clue of what goes
on though.

On Mon, Apr 30, 2012 at 08:33, Dov Grobgeld <[email-masked]> wrote:
> I finally ran emacs-24 under debugger to figure out where it got
> stuck. What I found was that it is stuck in keyboard.c where in
> read_key_sequence() the control keeps jumping back to the
> replay_sequence label. Does this ring a bell to someone?
>
> Regards,
> Dov
>
>
> On Wed, Jan 25, 2012 at 21:05, Glenn Morris <[email-masked]> wrote:
>> Dov Grobgeld wrote:
>>
>>> 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.
>>
>> Thanks for the detective work. I'm afraid I don't know what to do about
>> this. It looks like process handling is messed up somehow.
>>
>> I hope someone else on this list can help you further.