GNU bug report logs - #10580
24.0.92; gdb initialization takes more than one minute at 100% CPU

Previous Next

Full log

Message #29 received at 10580 <at> debbugs.gnu.org (full text, mbox):

From: Dov Grobgeld <dov.grobgeld <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 10580 <at> debbugs.gnu.org
Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute
	at 100% CPU
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 <dov.grobgeld <at> gmail.com> 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 <rgm <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.