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