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

Previous Next

Full log

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

From: Chong Yidong <cyd <at> gnu.org>
To: Dov Grobgeld <dov.grobgeld <at> gmail.com>
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, 07 May 2012 14:26:14 +0800

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,

Previous Next

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