[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:43:06 -0400 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 |
On 10/19/2011 4:26 PM, Eli Zaretskii wrote:
Date: Wed, 19 Oct 2011 16:00:09 -0400
From: Ken Brown<kbrown@cornell.edu>
CC: 9767@debbugs.gnu.org
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.
EINTR means that some signal arrived (assuming that Cygwin's `select'
is Posix-ish enough). The question is, which signal? Does Cygwin
provide any tools to see which signals were delivered to a program?
There's a program called strace that produces lots of debugging
information like this. I'll give it a try.
Also, the fact that `select' is interrupted doesn't necessarily mean
that the input arrival is ignored, does it? Doesn't
wait_reading_process_output loop around and examines the input
descriptors again? If not, why not? IOW, why should EINTR become a
failure?
No, wait_reading_process_output treats EINTR as though it meant there's
no input available. Here's the relevant code from process.c, line 4638.
if (nfds < 0)
{
if (xerrno == EINTR)
no_avail = 1;
Even worse, xg_select (which is what the Cygwin build uses) deliberately
returns -1 and sets errno = EINTR whenever the actual select call
returns 0. Here's the code from xg_select.c, line 141:
/* To not have to recalculate timeout, return like this. */
if (retval == 0)
{
retval = -1;
errno = EINTR;
}
I don't know the rationale for treating EINTR the same as no input
available, but I agree that it doesn't seem right.
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?
Atimers (those which are responsible for the "busy cursor" display)
could deliver SIGALRM, yes. But again, I don't see why this should
fail the loop that waits for input, and then only in this particular
case. Something else is at work here.
- bug#9767: 24.0.90; gdb initialization on Cygwin, Ken Brown, 2011/10/16
- bug#9767: 24.0.90; gdb initialization on Cygwin, Ken Brown, 2011/10/16
- bug#9767: 24.0.90; gdb initialization on Cygwin, Eli Zaretskii, 2011/10/17
- bug#9767: 24.0.90; gdb initialization on Cygwin, Ken Brown, 2011/10/19
- bug#9767: 24.0.90; gdb initialization on Cygwin, Eli Zaretskii, 2011/10/19
- bug#9767: 24.0.90; gdb initialization on Cygwin,
Ken Brown <=
- bug#9767: 24.0.90; gdb initialization on Cygwin, Andreas Schwab, 2011/10/19
- bug#9767: 24.0.90; gdb initialization on Cygwin, Eli Zaretskii, 2011/10/19
- bug#9767: 24.0.90; gdb initialization on Cygwin, Ken Brown, 2011/10/19
- bug#9767: 24.0.90; gdb initialization on Cygwin, Ken Brown, 2011/10/21
- bug#9767: 24.0.90; gdb initialization on Cygwin, Eli Zaretskii, 2011/10/21
- bug#9767: 24.0.90; gdb initialization on Cygwin, Ken Brown, 2011/10/22
- bug#9767: 24.0.90; gdb initialization on Cygwin, Ken Brown, 2011/10/22
- bug#9767: 24.0.90; gdb initialization on Cygwin, Ken Brown, 2011/10/23
- bug#9767: 24.0.90; gdb initialization on Cygwin, Stefan Monnier, 2011/10/21
- bug#9767: 24.0.90; gdb initialization on Cygwin, Ken Brown, 2011/10/22