Hi Chong,

In response to your questions.

During the "100% CPU" time period, emacs still responds normally and files
can be opened, etc.

My gdb version is "GNU gdb (GDB) Fedora (7.2-52.fc14)". I have tried it at
home as well with a later version from Fedora 16 and the result is the same.

I put breakpoints at the lines that you indicated, but as you suspected,
the breakpoints are only reached when I exit gdb with the "quit" command.

What's next? Thanks again for looking into this.

Dov




On Mon, May 7, 2012 at 5:53 AM, Chong Yidong <cyd@gnu.org> wrote:

> Dov Grobgeld <dov.grobgeld@gmail.com> writes:
>
> > The *input/output of a.out* is empty.
> >
> > It seems that I was wrong about read_key_sequence(). It doesn't
> > "return early".
>
> During this time, is Emacs responsive to user commands, i.e. does it
> work normally apart from taking 100% CPU?  Or is it just unresponsive?
>
> Also, what is your gdb version?
>
> Also, please set a breakpoint at process.c:4896, which should be the
> line
>
>                  struct Lisp_Process *p = XPROCESS (proc);
>
> as well as the function exec_sentinel().  See if Emacs hits each
> breakpoint, and step through it for the next several steps.  In
> exec_sentinel, please show the Lisp values of the `proc' and `reason'
> variables (i.e. `pp proc' and `pp reason'.)
>
> Basically, gdb-mi.el allocates a pty and passes it to the gdb process,
> which hooks the pty up to the debugged process's input/output.  That's
> what the "1-inferior-tty-set /dev/pts/9" gdb command does.  Emacs then
> listens for input/output on the pty.  Recently I fixed a bug in which
> Emacs would use 100% CPU due to Emacs getting an EIO error on that pty
> and then spinning; this fix involved setting up a sentinel that closes
> the pty when Emacs gets EIO; it's possible the fix is not working for
> you, though I don't know why.  The other possibility is that the program
> you are debugging does something strange with its input/output stream.
>
> Thanks.
>