bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9767: 24.0.90; gdb initialization on Cygwin


From: Ken Brown
Subject: bug#9767: 24.0.90; gdb initialization on Cygwin
Date: Wed, 19 Oct 2011 16:00:09 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

On 10/17/2011 1:39 AM, Eli Zaretskii wrote:
Date: Sun, 16 Oct 2011 19:08:32 -0400
From: Ken Brown<address@hidden>

Further info: It seems that initialization is actually completing, but
for some reason the buffer is not being redisplayed.  To test this, I
inserted (sit-for .1) at the end of gdb-update to force redisplay, and
that solved the problem.  Unless someone who understands redisplay can
figure out why redisplay isn't happening on Cygwin, I'm inclined to
apply the following patch:

My crystal ball says that redisplay isn't happening because Emacs
doesn't know that the GDB prompt has arrived.  The call to sit-for
causes Emacs to check its input descriptors, "discovering" that there
is input.

Please look around in wait_reading_process_output, and see what is
going on there, before and after the call to sit-for.  In particular,
does the call to `select' report that input has arrived from GDB?

Thanks for the suggestions, Eli. First of all, I was wrong when I said that the problem was redisplay: using sleep-for instead of sit-for works just as well. As your crystal ball predicted, the problem is that emacs hasn't read its input from GDB. Here's what happens:

After M-x gdb finishes its initialization, emacs goes into its command loop. read_char calls sit_for with a timeout of 30 seconds, and sit_for calls wait_reading_process_output, which calls select. The call to select fails immediately with EINTR. I don't understand the command loop well enough to know what's interrupting the select call. But select works fine in other settings (such as when I insert sleep-for in the gdb initialization).

It seems that the problem is not really about M-x gdb, but about the emacs command loop. I see the same kinds of select failures (always with EINTR) if I just start up emacs and watch the calls to select during the command loop.

The code in keyboard.c is full of alarms and timers, presumably related to polling for keyboard input. Could this polling be doing something that interrupts the select call under some circumstances?

Ken





reply via email to

[Prev in Thread] Current Thread [Next in Thread]