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

Previous Next

Package: emacs;

Reported by: Dov Grobgeld <dov.grobgeld <at> gmail.com>

Date: Sun, 22 Jan 2012 17:55:03 UTC

Severity: important

Tags: patch

Found in version 24.0.92

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


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

From: Dov Grobgeld <dov.grobgeld <at> gmail.com>
To: Chong Yidong <cyd <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: Tue, 8 May 2012 10:56:21 +0300
[Message part 1 (text/plain, inline)]
Some more info that I found through strace that might help. Alltogether
read_process_output() is called 214 times and thus a total of 870k of text
is read through /dev/ptmx to read_process_output() . Could the amount of
data possibly explain the slowness?

Regards,
Dov

On Tue, May 8, 2012 at 8:33 AM, Dov Grobgeld <dov.grobgeld <at> gmail.com> wrote:

> I added the above patch and the result is as follows:
>
> After the following two lines:
>
>
>     nread = read_process_output (proc, channel);
>
>     pp = XPROCESS(proc);
>
> nread==4095, pp->pid=1234 repeatedly. (Actually 1234 seems to be an
> arbitrary, but constant number between 1000 and 2000).
>
> This seems strange, as obviously the sub-process does not produce 4095
> characters repeatedly.
>
> Thanks,
> Dov
>
> On Mon, May 7, 2012 at 9:26 AM, Chong Yidong <cyd <at> gnu.org> wrote:
>
>> Actually, try the following patch instead (apparently gdb has some
>> issues with printing errno).  Apply the patch, then when Emacs is taking
>> 100% CPU do an interrupt and set the breakpoint at process.c:4855, then
>> when the breakpoint triggers do
>>
>> n
>> p nread
>> p errno
>>
>> and step through the subsequent if/else blocks.  Thanks.
>>
>> Basically, the 100% CPU appears to be because Emacs' select() call keeps
>> getting worken up by the pty attached to your program.  But, for some
>> reason, no actual output being read from that pty.  These debugging
>> steps are trying to figure out if some uncaught errno is being reported
>> by the pty read.
>>
>>
>> === modified file 'src/process.c'
>> *** src/process.c       2012-04-20 06:39:29 +0000
>> --- src/process.c       2012-05-07 06:21:39 +0000
>> ***************
>> *** 4822,4827 ****
>> --- 4822,4829 ----
>>                && !FD_ISSET (channel, &non_process_wait_mask))
>>            {
>>              int nread;
>> +             int saved_errno = 0;
>> +             struct Lisp_Process *pp;
>>
>>              /* If waiting for this channel, arrange to return as
>>                 soon as no more input to be processed.  No more
>> ***************
>> *** 4847,4852 ****
>> --- 4849,4859 ----
>>                  buffered-ahead character if we have one.  */
>>
>>              nread = read_process_output (proc, channel);
>> +
>> +             pp = XPROCESS (proc);
>> +             if (pp->pid == -2)
>> +               saved_errno = errno;
>> +
>>              if (nread > 0)
>>                {
>>                  /* Since read_process_output can run a filter,
>>
>>
>
[Message part 2 (text/html, inline)]

This bug report was last modified 12 years and 74 days ago.

Previous Next


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