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@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,