* Question about Cygwin's select() @ 2011-10-19 13:29 Ken Brown 2011-10-19 14:49 ` Corinna Vinschen 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2011-10-19 13:29 UTC (permalink / raw) To: cygwin I'm trying to debug an emacs problem, and I'm running into something I don't understand involving Cygwin's select. I'll try to make an STC if necessary, but I thought I'd start with a verbal description in case there's an easy answer. Here's the situation: emacs creates a subprocess running gdb and sends a bunch of commands to gdb without immediately reading the resulting output. emacs then goes into a loop in which it waits for keyboard input and periodically calls select to check for output from subprocesses. The first call to select has a 30 second timeout and *always* fails with EINTR. As a result, emacs doesn't read the output from gdb right away and doesn't properly initialize the gdb buffer. Subsequent calls to select sometimes succeed and sometimes fail. When I'm running emacs under gdb and stepping through it, the buffer eventually gets initialized. When I'm running emacs outside of gdb, the buffer doesn't get initialized until I press Return. I have a simple workaround for this, but I'd like to be sure there isn't some underlying bug that I'm masking with the workaround. So my question is this: Is there some reason that I should expect that first call to select to consistently fail with EINTR, or might this indicate a bug? I realize that it might not be possible to answer the question based on the information I've provided, but I thought it was worth a try. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-19 13:29 Question about Cygwin's select() Ken Brown @ 2011-10-19 14:49 ` Corinna Vinschen 2011-10-19 15:29 ` Ken Brown 2011-10-19 16:22 ` Christopher Faylor 0 siblings, 2 replies; 15+ messages in thread From: Corinna Vinschen @ 2011-10-19 14:49 UTC (permalink / raw) To: cygwin On Oct 19 09:28, Ken Brown wrote: > I'm trying to debug an emacs problem, and I'm running into something > I don't understand involving Cygwin's select. I'll try to make an > STC if necessary, but I thought I'd start with a verbal description > in case there's an easy answer. Here's the situation: > > emacs creates a subprocess running gdb and sends a bunch of commands > to gdb without immediately reading the resulting output. emacs then > goes into a loop in which it waits for keyboard input and > periodically calls select to check for output from subprocesses. > The first call to select has a 30 second timeout and *always* fails > with EINTR. As a result, emacs doesn't read the output from gdb > right away and doesn't properly initialize the gdb buffer. > Subsequent calls to select sometimes succeed and sometimes fail. > When I'm running emacs under gdb and stepping through it, the buffer > eventually gets initialized. When I'm running emacs outside of gdb, > the buffer doesn't get initialized until I press Return. > > I have a simple workaround for this, but I'd like to be sure there > isn't some underlying bug that I'm masking with the workaround. So > my question is this: Is there some reason that I should expect that > first call to select to consistently fail with EINTR, or might this > indicate a bug? > > I realize that it might not be possible to answer the question based > on the information I've provided, but I thought it was worth a try. Some details are missing like the objects used to communicate with GDB. Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or with 1.7.9? And what's your workaround? The EINTR sounds weird. A testcase would be most helpful. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-19 14:49 ` Corinna Vinschen @ 2011-10-19 15:29 ` Ken Brown 2011-10-19 16:22 ` Christopher Faylor 1 sibling, 0 replies; 15+ messages in thread From: Ken Brown @ 2011-10-19 15:29 UTC (permalink / raw) To: cygwin On 10/19/2011 10:49 AM, Corinna Vinschen wrote: > On Oct 19 09:28, Ken Brown wrote: >> I'm trying to debug an emacs problem, and I'm running into something >> I don't understand involving Cygwin's select. I'll try to make an >> STC if necessary, but I thought I'd start with a verbal description >> in case there's an easy answer. Here's the situation: >> >> emacs creates a subprocess running gdb and sends a bunch of commands >> to gdb without immediately reading the resulting output. emacs then >> goes into a loop in which it waits for keyboard input and >> periodically calls select to check for output from subprocesses. >> The first call to select has a 30 second timeout and *always* fails >> with EINTR. As a result, emacs doesn't read the output from gdb >> right away and doesn't properly initialize the gdb buffer. >> Subsequent calls to select sometimes succeed and sometimes fail. >> When I'm running emacs under gdb and stepping through it, the buffer >> eventually gets initialized. When I'm running emacs outside of gdb, >> the buffer doesn't get initialized until I press Return. >> >> I have a simple workaround for this, but I'd like to be sure there >> isn't some underlying bug that I'm masking with the workaround. So >> my question is this: Is there some reason that I should expect that >> first call to select to consistently fail with EINTR, or might this >> indicate a bug? >> >> I realize that it might not be possible to answer the question based >> on the information I've provided, but I thought it was worth a try. > > Some details are missing like the objects used to communicate with GDB. > Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or > with 1.7.9? And what's your workaround? The EINTR sounds weird. A > testcase would be most helpful. Sorry for the missing details. Emacs uses a pseudo tty. I'm currently using the latest Cygwin snapshot, but I'm pretty sure I saw the same behavior with 1.7.9. I'll recheck that. My workaround is to force emacs to check for process output earlier in the initialization phase. For reasons I don't understand, the select call used at that point always succeeds. I think you've answered my basic question by saying that the EINTR sounds weird. I'll try to make a testcase. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-19 14:49 ` Corinna Vinschen 2011-10-19 15:29 ` Ken Brown @ 2011-10-19 16:22 ` Christopher Faylor 2011-10-19 17:32 ` Ken Brown 1 sibling, 1 reply; 15+ messages in thread From: Christopher Faylor @ 2011-10-19 16:22 UTC (permalink / raw) To: cygwin On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote: >On Oct 19 09:28, Ken Brown wrote: >> I'm trying to debug an emacs problem, and I'm running into something >> I don't understand involving Cygwin's select. I'll try to make an >> STC if necessary, but I thought I'd start with a verbal description >> in case there's an easy answer. Here's the situation: >> >> emacs creates a subprocess running gdb and sends a bunch of commands >> to gdb without immediately reading the resulting output. emacs then >> goes into a loop in which it waits for keyboard input and >> periodically calls select to check for output from subprocesses. >> The first call to select has a 30 second timeout and *always* fails >> with EINTR. As a result, emacs doesn't read the output from gdb >> right away and doesn't properly initialize the gdb buffer. >> Subsequent calls to select sometimes succeed and sometimes fail. >> When I'm running emacs under gdb and stepping through it, the buffer >> eventually gets initialized. When I'm running emacs outside of gdb, >> the buffer doesn't get initialized until I press Return. >> >> I have a simple workaround for this, but I'd like to be sure there >> isn't some underlying bug that I'm masking with the workaround. So >> my question is this: Is there some reason that I should expect that >> first call to select to consistently fail with EINTR, or might this >> indicate a bug? >> >> I realize that it might not be possible to answer the question based >> on the information I've provided, but I thought it was worth a try. > >Some details are missing like the objects used to communicate with GDB. >Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or >with 1.7.9? And what's your workaround? The EINTR sounds weird. A >testcase would be most helpful. It isn't clear if you're getting the EINTR by looking at strace output or from the code. If it's strace then be aware that sometimes the output just reports the current errno regardless of whether there is an error or not. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-19 16:22 ` Christopher Faylor @ 2011-10-19 17:32 ` Ken Brown 2011-10-19 20:15 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2011-10-19 17:32 UTC (permalink / raw) To: cygwin On 10/19/2011 12:22 PM, Christopher Faylor wrote: > On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote: >> On Oct 19 09:28, Ken Brown wrote: >>> I'm trying to debug an emacs problem, and I'm running into something >>> I don't understand involving Cygwin's select. I'll try to make an >>> STC if necessary, but I thought I'd start with a verbal description >>> in case there's an easy answer. Here's the situation: >>> >>> emacs creates a subprocess running gdb and sends a bunch of commands >>> to gdb without immediately reading the resulting output. emacs then >>> goes into a loop in which it waits for keyboard input and >>> periodically calls select to check for output from subprocesses. >>> The first call to select has a 30 second timeout and *always* fails >>> with EINTR. As a result, emacs doesn't read the output from gdb >>> right away and doesn't properly initialize the gdb buffer. >>> Subsequent calls to select sometimes succeed and sometimes fail. >>> When I'm running emacs under gdb and stepping through it, the buffer >>> eventually gets initialized. When I'm running emacs outside of gdb, >>> the buffer doesn't get initialized until I press Return. >>> >>> I have a simple workaround for this, but I'd like to be sure there >>> isn't some underlying bug that I'm masking with the workaround. So >>> my question is this: Is there some reason that I should expect that >>> first call to select to consistently fail with EINTR, or might this >>> indicate a bug? >>> >>> I realize that it might not be possible to answer the question based >>> on the information I've provided, but I thought it was worth a try. >> >> Some details are missing like the objects used to communicate with GDB. >> Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or >> with 1.7.9? And what's your workaround? The EINTR sounds weird. A >> testcase would be most helpful. > > It isn't clear if you're getting the EINTR by looking at strace output > or from the code. If it's strace then be aware that sometimes the > output just reports the current errno regardless of whether there is an > error or not. I'm getting the EINTR by examining errno while running the program under gdb. But thanks for the heads-up about strace. I didn't know that. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-19 17:32 ` Ken Brown @ 2011-10-19 20:15 ` Ken Brown 2011-10-19 20:31 ` Jon Clugston 2011-10-20 12:14 ` Ken Brown 0 siblings, 2 replies; 15+ messages in thread From: Ken Brown @ 2011-10-19 20:15 UTC (permalink / raw) To: cygwin On 10/19/2011 1:32 PM, Ken Brown wrote: > On 10/19/2011 12:22 PM, Christopher Faylor wrote: >> On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote: >>> On Oct 19 09:28, Ken Brown wrote: >>>> I'm trying to debug an emacs problem, and I'm running into something >>>> I don't understand involving Cygwin's select. I'll try to make an >>>> STC if necessary, but I thought I'd start with a verbal description >>>> in case there's an easy answer. Here's the situation: >>>> >>>> emacs creates a subprocess running gdb and sends a bunch of commands >>>> to gdb without immediately reading the resulting output. emacs then >>>> goes into a loop in which it waits for keyboard input and >>>> periodically calls select to check for output from subprocesses. >>>> The first call to select has a 30 second timeout and *always* fails >>>> with EINTR. As a result, emacs doesn't read the output from gdb >>>> right away and doesn't properly initialize the gdb buffer. >>>> Subsequent calls to select sometimes succeed and sometimes fail. >>>> When I'm running emacs under gdb and stepping through it, the buffer >>>> eventually gets initialized. When I'm running emacs outside of gdb, >>>> the buffer doesn't get initialized until I press Return. >>>> >>>> I have a simple workaround for this, but I'd like to be sure there >>>> isn't some underlying bug that I'm masking with the workaround. So >>>> my question is this: Is there some reason that I should expect that >>>> first call to select to consistently fail with EINTR, or might this >>>> indicate a bug? >>>> >>>> I realize that it might not be possible to answer the question based >>>> on the information I've provided, but I thought it was worth a try. >>> >>> Some details are missing like the objects used to communicate with GDB. >>> Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or >>> with 1.7.9? And what's your workaround? The EINTR sounds weird. A >>> testcase would be most helpful. >> >> It isn't clear if you're getting the EINTR by looking at strace output >> or from the code. If it's strace then be aware that sometimes the >> output just reports the current errno regardless of whether there is an >> error or not. > > I'm getting the EINTR by examining errno while running the program under > gdb. But thanks for the heads-up about strace. I didn't know that. I don't have a testcase yet, but I have a clearer idea of what's happening. It actually has nothing to do with the gdb subprocess, but rather is a problem that can occur whenever emacs is running its main command loop. emacs polls for keyboard input while also using select to check for output from subprocesses. It's in this setting that select often fails with EINTR, even when there are no subprocesses running. I wonder if the keyboard polling is doing something that interrupts the select call. Unfortunately, the keyboard code (in src/keyboard.c) is full of alarms and timers and other things I know nothing about, so it's not going to be easy for me to come up with an STC. I'll see if I can get help on the emacs-devel list. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-19 20:15 ` Ken Brown @ 2011-10-19 20:31 ` Jon Clugston 2011-10-20 2:39 ` Ken Brown 2011-10-20 12:14 ` Ken Brown 1 sibling, 1 reply; 15+ messages in thread From: Jon Clugston @ 2011-10-19 20:31 UTC (permalink / raw) To: cygwin On Wed, Oct 19, 2011 at 4:15 PM, Ken Brown <kbrown@cornell.edu> wrote: > On 10/19/2011 1:32 PM, Ken Brown wrote: >> >> On 10/19/2011 12:22 PM, Christopher Faylor wrote: >>> >>> On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote: >>>> >>>> On Oct 19 09:28, Ken Brown wrote: >>>>> >>>>> I'm trying to debug an emacs problem, and I'm running into something >>>>> I don't understand involving Cygwin's select. I'll try to make an >>>>> STC if necessary, but I thought I'd start with a verbal description >>>>> in case there's an easy answer. Here's the situation: >>>>> >>>>> emacs creates a subprocess running gdb and sends a bunch of commands >>>>> to gdb without immediately reading the resulting output. emacs then >>>>> goes into a loop in which it waits for keyboard input and >>>>> periodically calls select to check for output from subprocesses. >>>>> The first call to select has a 30 second timeout and *always* fails >>>>> with EINTR. As a result, emacs doesn't read the output from gdb >>>>> right away and doesn't properly initialize the gdb buffer. >>>>> Subsequent calls to select sometimes succeed and sometimes fail. >>>>> When I'm running emacs under gdb and stepping through it, the buffer >>>>> eventually gets initialized. When I'm running emacs outside of gdb, >>>>> the buffer doesn't get initialized until I press Return. >>>>> >>>>> I have a simple workaround for this, but I'd like to be sure there >>>>> isn't some underlying bug that I'm masking with the workaround. So >>>>> my question is this: Is there some reason that I should expect that >>>>> first call to select to consistently fail with EINTR, or might this >>>>> indicate a bug? >>>>> >>>>> I realize that it might not be possible to answer the question based >>>>> on the information I've provided, but I thought it was worth a try. >>>> >>>> Some details are missing like the objects used to communicate with GDB. >>>> Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or >>>> with 1.7.9? And what's your workaround? The EINTR sounds weird. A >>>> testcase would be most helpful. >>> >>> It isn't clear if you're getting the EINTR by looking at strace output >>> or from the code. If it's strace then be aware that sometimes the >>> output just reports the current errno regardless of whether there is an >>> error or not. >> >> I'm getting the EINTR by examining errno while running the program under >> gdb. But thanks for the heads-up about strace. I didn't know that. > > I don't have a testcase yet, but I have a clearer idea of what's happening. > It actually has nothing to do with the gdb subprocess, but rather is a > problem that can occur whenever emacs is running its main command loop. > emacs polls for keyboard input while also using select to check for output > from subprocesses. It's in this setting that select often fails with EINTR, > even when there are no subprocesses running. I wonder if the keyboard > polling is doing something that interrupts the select call. > > Unfortunately, the keyboard code (in src/keyboard.c) is full of alarms and > timers and other things I know nothing about, so it's not going to be easy > for me to come up with an STC. I'll see if I can get help on the > emacs-devel list. > > Ken > Any code calling "select" (and many other kernel calls) must handle the case of the call returning EINTR for many (or no particular) reason(s). If emacs is assuming certain calls under certain conditions will never return EINTR, then it is definitely not written robustly. Jon -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-19 20:31 ` Jon Clugston @ 2011-10-20 2:39 ` Ken Brown 0 siblings, 0 replies; 15+ messages in thread From: Ken Brown @ 2011-10-20 2:39 UTC (permalink / raw) To: cygwin On 10/19/2011 4:30 PM, Jon Clugston wrote: > On Wed, Oct 19, 2011 at 4:15 PM, Ken Brown<kbrown@cornell.edu> wrote: >> On 10/19/2011 1:32 PM, Ken Brown wrote: >>> >>> On 10/19/2011 12:22 PM, Christopher Faylor wrote: >>>> >>>> On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote: >>>>> >>>>> On Oct 19 09:28, Ken Brown wrote: >>>>>> >>>>>> I'm trying to debug an emacs problem, and I'm running into something >>>>>> I don't understand involving Cygwin's select. I'll try to make an >>>>>> STC if necessary, but I thought I'd start with a verbal description >>>>>> in case there's an easy answer. Here's the situation: >>>>>> >>>>>> emacs creates a subprocess running gdb and sends a bunch of commands >>>>>> to gdb without immediately reading the resulting output. emacs then >>>>>> goes into a loop in which it waits for keyboard input and >>>>>> periodically calls select to check for output from subprocesses. >>>>>> The first call to select has a 30 second timeout and *always* fails >>>>>> with EINTR. As a result, emacs doesn't read the output from gdb >>>>>> right away and doesn't properly initialize the gdb buffer. >>>>>> Subsequent calls to select sometimes succeed and sometimes fail. >>>>>> When I'm running emacs under gdb and stepping through it, the buffer >>>>>> eventually gets initialized. When I'm running emacs outside of gdb, >>>>>> the buffer doesn't get initialized until I press Return. >>>>>> >>>>>> I have a simple workaround for this, but I'd like to be sure there >>>>>> isn't some underlying bug that I'm masking with the workaround. So >>>>>> my question is this: Is there some reason that I should expect that >>>>>> first call to select to consistently fail with EINTR, or might this >>>>>> indicate a bug? >>>>>> >>>>>> I realize that it might not be possible to answer the question based >>>>>> on the information I've provided, but I thought it was worth a try. >>>>> >>>>> Some details are missing like the objects used to communicate with GDB. >>>>> Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or >>>>> with 1.7.9? And what's your workaround? The EINTR sounds weird. A >>>>> testcase would be most helpful. >>>> >>>> It isn't clear if you're getting the EINTR by looking at strace output >>>> or from the code. If it's strace then be aware that sometimes the >>>> output just reports the current errno regardless of whether there is an >>>> error or not. >>> >>> I'm getting the EINTR by examining errno while running the program under >>> gdb. But thanks for the heads-up about strace. I didn't know that. >> >> I don't have a testcase yet, but I have a clearer idea of what's happening. >> It actually has nothing to do with the gdb subprocess, but rather is a >> problem that can occur whenever emacs is running its main command loop. >> emacs polls for keyboard input while also using select to check for output >> from subprocesses. It's in this setting that select often fails with EINTR, >> even when there are no subprocesses running. I wonder if the keyboard >> polling is doing something that interrupts the select call. >> >> Unfortunately, the keyboard code (in src/keyboard.c) is full of alarms and >> timers and other things I know nothing about, so it's not going to be easy >> for me to come up with an STC. I'll see if I can get help on the >> emacs-devel list. >> >> Ken >> > > Any code calling "select" (and many other kernel calls) must handle > the case of the call returning EINTR for many (or no particular) > reason(s). If emacs is assuming certain calls under certain > conditions will never return EINTR, then it is definitely not written > robustly. emacs does handle the EINTR. Sorry if I suggested otherwise. I was just surprised that I was getting that error so often, and I thought it was responsible for the gdb problem I was seeing. I'll keep debugging. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-19 20:15 ` Ken Brown 2011-10-19 20:31 ` Jon Clugston @ 2011-10-20 12:14 ` Ken Brown 2011-10-21 9:45 ` Corinna Vinschen 1 sibling, 1 reply; 15+ messages in thread From: Ken Brown @ 2011-10-20 12:14 UTC (permalink / raw) To: cygwin On 10/19/2011 4:15 PM, Ken Brown wrote: > I don't have a testcase yet, but I have a clearer idea of what's > happening. It actually has nothing to do with the gdb subprocess, but > rather is a problem that can occur whenever emacs is running its main > command loop. emacs polls for keyboard input while also using select to > check for output from subprocesses. It's in this setting that select > often fails with EINTR, even when there are no subprocesses running. I > wonder if the keyboard polling is doing something that interrupts the > select call. I think this guess is correct. If I start up emacs and do nothing, strace shows many sequences like the following: - emacs calls select - a timer sends SIGALRM - select returns -1 with error EINTR The EINTR isn't actually visible in the strace output, but I do see "select_stuff::wait: signal received". A glance at select.cc indicates that this is the debug output produced by select when it is about to return -1 with EINTR. These sequences always occur in connection with start_thread_socket. I've appended a typical excerpt from the strace output below. Please let me know if you need to see more strace output. I didn't want to spam the list by sending too much. You still might need more information, but I can at least refine my original question: Is it reasonable that select should give up and return -1 because a timer has sent SIGALRM? Ken [...] 686 8226742 [main] emacs 6772 cygwin_select: 6, 0x28C134, 0x28C12C, 0x0, 0x28C200 [...] 106 8227514 [main] emacs 6772 select_stuff::wait: m 4, ms 464 49 8227563 [select_socket] emacs 6772 thread_socket: stuff_start 0x28C098 53 8227616 [select_socket] emacs 6772 peek_socket: read_ready: 0, write_ready: 0, except_ready: 0 2501 8230117 [itimer] emacs 6772 timer_thread: timed out 66 8230183 [itimer] emacs 6772 timer_thread: 0x6118D560 sending sig 14 52 8230235 [itimer] emacs 6772 sig_send: sendsig 0x104, pid 6772, signal 14, its_me 1 52 8230287 [itimer] emacs 6772 sig_send: Not waiting for sigcomplete. its_me 1 signal 14 5 8230292 [sig] emacs 6772 sigpacket::process: signal 14 processing 35 8230327 [itimer] emacs 6772 sig_send: returning 0x0 from sending signal 14 28 8230355 [sig] emacs 6772 _cygtls::find_tls: sig 14 61 8230416 [sig] emacs 6772 sigpacket::process: signal 14, about to call 0x5E85A8 37 8230453 [sig] emacs 6772 setup_handler: controlled interrupt. stackptr 0x28DA34, stack 0x28DA30, stackptr[-1] 0x4F2F4C [...] 35 8230632 [sig] emacs 6772 _cygtls::interrupt_setup: armed signal_arrived 0x154, sig 14, res 1 57 8230689 [sig] emacs 6772 setup_handler: signal 14 delivered 40 8230729 [sig] emacs 6772 sigpacket::process: returning 1 51 8230780 [main] emacs 6772 select_stuff::cleanup: calling cleanup routines 596 8231376 [main] emacs 6772 socket_cleanup: si 0x8016D220 si->thread 0x611773F0 307 8231683 [select_socket] emacs 6772 thread_socket: leaving thread_socket 696 8232379 [main] emacs 6772 socket_cleanup: returning 56 8232435 [main] emacs 6772 select_stuff::wait: signal received -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-20 12:14 ` Ken Brown @ 2011-10-21 9:45 ` Corinna Vinschen 2011-10-21 14:27 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Corinna Vinschen @ 2011-10-21 9:45 UTC (permalink / raw) To: cygwin On Oct 20 08:13, Ken Brown wrote: > On 10/19/2011 4:15 PM, Ken Brown wrote: > >I don't have a testcase yet, but I have a clearer idea of what's > >happening. It actually has nothing to do with the gdb subprocess, but > >rather is a problem that can occur whenever emacs is running its main > >command loop. emacs polls for keyboard input while also using select to > >check for output from subprocesses. It's in this setting that select > >often fails with EINTR, even when there are no subprocesses running. I > >wonder if the keyboard polling is doing something that interrupts the > >select call. > > I think this guess is correct. If I start up emacs and do nothing, > strace shows many sequences like the following: > > - emacs calls select > - a timer sends SIGALRM > - select returns -1 with error EINTR > > The EINTR isn't actually visible in the strace output, but I do see > "select_stuff::wait: signal received". A glance at select.cc > indicates that this is the debug output produced by select when it > is about to return -1 with EINTR. > > These sequences always occur in connection with start_thread_socket. > I've appended a typical excerpt from the strace output below. > Please let me know if you need to see more strace output. I didn't > want to spam the list by sending too much. > > You still might need more information, but I can at least refine my > original question: Is it reasonable that select should give up and > return -1 because a timer has sent SIGALRM? If SIGALRM isn't blocked, then, yes. What is setting up the timer? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-21 9:45 ` Corinna Vinschen @ 2011-10-21 14:27 ` Ken Brown 2011-10-21 15:45 ` Jon Clugston 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2011-10-21 14:27 UTC (permalink / raw) To: cygwin On 10/21/2011 5:44 AM, Corinna Vinschen wrote: > On Oct 20 08:13, Ken Brown wrote: >> On 10/19/2011 4:15 PM, Ken Brown wrote: >>> I don't have a testcase yet, but I have a clearer idea of what's >>> happening. It actually has nothing to do with the gdb subprocess, but >>> rather is a problem that can occur whenever emacs is running its main >>> command loop. emacs polls for keyboard input while also using select to >>> check for output from subprocesses. It's in this setting that select >>> often fails with EINTR, even when there are no subprocesses running. I >>> wonder if the keyboard polling is doing something that interrupts the >>> select call. >> >> I think this guess is correct. If I start up emacs and do nothing, >> strace shows many sequences like the following: >> >> - emacs calls select >> - a timer sends SIGALRM >> - select returns -1 with error EINTR >> >> The EINTR isn't actually visible in the strace output, but I do see >> "select_stuff::wait: signal received". A glance at select.cc >> indicates that this is the debug output produced by select when it >> is about to return -1 with EINTR. >> >> These sequences always occur in connection with start_thread_socket. >> I've appended a typical excerpt from the strace output below. >> Please let me know if you need to see more strace output. I didn't >> want to spam the list by sending too much. >> >> You still might need more information, but I can at least refine my >> original question: Is it reasonable that select should give up and >> return -1 because a timer has sent SIGALRM? > > If SIGALRM isn't blocked, then, yes. What is setting up the timer? Emacs sets up the timer. But I just looked at the code in which emacs calls select, and it looks like it reduces the select timeout to make sure that select will return before the next SIGALRM is expected. I don't know why that's not working. By the way, I added debug code to emacs to make it print the return value after every call to select. If I then start emacs and do nothing, I get a message every second or two saying that select failed. If I press a key, select succeeds once or twice before it starts failing again. I'll keep trying to figure out what's going on. Ken Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-21 14:27 ` Ken Brown @ 2011-10-21 15:45 ` Jon Clugston 2011-10-21 20:03 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Jon Clugston @ 2011-10-21 15:45 UTC (permalink / raw) To: cygwin On Fri, Oct 21, 2011 at 10:26 AM, Ken Brown <kbrown@cornell.edu> wrote: > On 10/21/2011 5:44 AM, Corinna Vinschen wrote: >> >> On Oct 20 08:13, Ken Brown wrote: >>> >>> On 10/19/2011 4:15 PM, Ken Brown wrote: >>>> >>>> I don't have a testcase yet, but I have a clearer idea of what's >>>> happening. It actually has nothing to do with the gdb subprocess, but >>>> rather is a problem that can occur whenever emacs is running its main >>>> command loop. emacs polls for keyboard input while also using select to >>>> check for output from subprocesses. It's in this setting that select >>>> often fails with EINTR, even when there are no subprocesses running. I >>>> wonder if the keyboard polling is doing something that interrupts the >>>> select call. >>> >>> I think this guess is correct. If I start up emacs and do nothing, >>> strace shows many sequences like the following: >>> >>> - emacs calls select >>> - a timer sends SIGALRM >>> - select returns -1 with error EINTR >>> >>> The EINTR isn't actually visible in the strace output, but I do see >>> "select_stuff::wait: signal received". A glance at select.cc >>> indicates that this is the debug output produced by select when it >>> is about to return -1 with EINTR. >>> >>> These sequences always occur in connection with start_thread_socket. >>> I've appended a typical excerpt from the strace output below. >>> Please let me know if you need to see more strace output. I didn't >>> want to spam the list by sending too much. >>> >>> You still might need more information, but I can at least refine my >>> original question: Is it reasonable that select should give up and >>> return -1 because a timer has sent SIGALRM? >> >> If SIGALRM isn't blocked, then, yes. What is setting up the timer? > > Emacs sets up the timer. But I just looked at the code in which emacs calls > select, and it looks like it reduces the select timeout to make sure that > select will return before the next SIGALRM is expected. I don't know why > that's not working. There is absolutely no guarantee that you can do that. If the process is put to sleep between the computation of the select timeout and the actual call to "select", this logic fails. If the code assumes that it can reliably cause "select" to time out before a pending alarm expires, then it is broken. Jon -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-21 15:45 ` Jon Clugston @ 2011-10-21 20:03 ` Ken Brown 2011-10-22 9:55 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2011-10-21 20:03 UTC (permalink / raw) To: cygwin On 10/21/2011 11:45 AM, Jon Clugston wrote: > On Fri, Oct 21, 2011 at 10:26 AM, Ken Brown<kbrown@cornell.edu> wrote: >> On 10/21/2011 5:44 AM, Corinna Vinschen wrote: >>> >>> On Oct 20 08:13, Ken Brown wrote: >>>> >>>> On 10/19/2011 4:15 PM, Ken Brown wrote: >>>>> >>>>> I don't have a testcase yet, but I have a clearer idea of what's >>>>> happening. It actually has nothing to do with the gdb subprocess, but >>>>> rather is a problem that can occur whenever emacs is running its main >>>>> command loop. emacs polls for keyboard input while also using select to >>>>> check for output from subprocesses. It's in this setting that select >>>>> often fails with EINTR, even when there are no subprocesses running. I >>>>> wonder if the keyboard polling is doing something that interrupts the >>>>> select call. >>>> >>>> I think this guess is correct. If I start up emacs and do nothing, >>>> strace shows many sequences like the following: >>>> >>>> - emacs calls select >>>> - a timer sends SIGALRM >>>> - select returns -1 with error EINTR >>>> >>>> The EINTR isn't actually visible in the strace output, but I do see >>>> "select_stuff::wait: signal received". A glance at select.cc >>>> indicates that this is the debug output produced by select when it >>>> is about to return -1 with EINTR. >>>> >>>> These sequences always occur in connection with start_thread_socket. >>>> I've appended a typical excerpt from the strace output below. >>>> Please let me know if you need to see more strace output. I didn't >>>> want to spam the list by sending too much. >>>> >>>> You still might need more information, but I can at least refine my >>>> original question: Is it reasonable that select should give up and >>>> return -1 because a timer has sent SIGALRM? >>> >>> If SIGALRM isn't blocked, then, yes. What is setting up the timer? >> >> Emacs sets up the timer. But I just looked at the code in which emacs calls >> select, and it looks like it reduces the select timeout to make sure that >> select will return before the next SIGALRM is expected. I don't know why >> that's not working. > > There is absolutely no guarantee that you can do that. If the process > is put to sleep between the computation of the select timeout and the > actual call to "select", this logic fails. If the code assumes that > it can reliably cause "select" to time out before a pending alarm > expires, then it is broken. You're right. Blocking SIGALRM before the call to select (in the situation where the timeout was reduced) seems to fix the problem. I still have to do some more testing, but so far it looks good. Thanks. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-21 20:03 ` Ken Brown @ 2011-10-22 9:55 ` Ken Brown 2011-10-22 20:42 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2011-10-22 9:55 UTC (permalink / raw) To: cygwin On 10/21/2011 4:03 PM, Ken Brown wrote: > On 10/21/2011 11:45 AM, Jon Clugston wrote: >> On Fri, Oct 21, 2011 at 10:26 AM, Ken Brown<kbrown@cornell.edu> wrote: >>> On 10/21/2011 5:44 AM, Corinna Vinschen wrote: >>>> >>>> On Oct 20 08:13, Ken Brown wrote: >>>>> >>>>> On 10/19/2011 4:15 PM, Ken Brown wrote: >>>>>> >>>>>> I don't have a testcase yet, but I have a clearer idea of what's >>>>>> happening. It actually has nothing to do with the gdb subprocess, but >>>>>> rather is a problem that can occur whenever emacs is running its main >>>>>> command loop. emacs polls for keyboard input while also using >>>>>> select to >>>>>> check for output from subprocesses. It's in this setting that select >>>>>> often fails with EINTR, even when there are no subprocesses >>>>>> running. I >>>>>> wonder if the keyboard polling is doing something that interrupts the >>>>>> select call. >>>>> >>>>> I think this guess is correct. If I start up emacs and do nothing, >>>>> strace shows many sequences like the following: >>>>> >>>>> - emacs calls select >>>>> - a timer sends SIGALRM >>>>> - select returns -1 with error EINTR >>>>> >>>>> The EINTR isn't actually visible in the strace output, but I do see >>>>> "select_stuff::wait: signal received". A glance at select.cc >>>>> indicates that this is the debug output produced by select when it >>>>> is about to return -1 with EINTR. >>>>> >>>>> These sequences always occur in connection with start_thread_socket. >>>>> I've appended a typical excerpt from the strace output below. >>>>> Please let me know if you need to see more strace output. I didn't >>>>> want to spam the list by sending too much. >>>>> >>>>> You still might need more information, but I can at least refine my >>>>> original question: Is it reasonable that select should give up and >>>>> return -1 because a timer has sent SIGALRM? >>>> >>>> If SIGALRM isn't blocked, then, yes. What is setting up the timer? >>> >>> Emacs sets up the timer. But I just looked at the code in which emacs >>> calls >>> select, and it looks like it reduces the select timeout to make sure >>> that >>> select will return before the next SIGALRM is expected. I don't know why >>> that's not working. >> >> There is absolutely no guarantee that you can do that. If the process >> is put to sleep between the computation of the select timeout and the >> actual call to "select", this logic fails. If the code assumes that >> it can reliably cause "select" to time out before a pending alarm >> expires, then it is broken. > > You're right. Blocking SIGALRM before the call to select (in the > situation where the timeout was reduced) seems to fix the problem. I'm wrong. I've been focusing too much on the select interruption. This is actually harmless and is correctly treated by emacs the same as a select timeout. It doesn't explain or solve the original gdb problem. Sorry for the noise. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Question about Cygwin's select() 2011-10-22 9:55 ` Ken Brown @ 2011-10-22 20:42 ` Ken Brown 0 siblings, 0 replies; 15+ messages in thread From: Ken Brown @ 2011-10-22 20:42 UTC (permalink / raw) To: cygwin On 10/22/2011 5:55 AM, Ken Brown wrote: > I'm wrong. I've been focusing too much on the select interruption. This > is actually harmless and is correctly treated by emacs the same as a > select timeout. It doesn't explain or solve the original gdb problem. > Sorry for the noise. I was finally able to make a testcase, showing that the problem I mentioned in the first post of this thread has nothing to do with emacs or select. It's a Cygwin/gdb problem. I've reported it in http://cygwin.com/ml/cygwin/2011-10/msg00445.html Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-10-22 20:42 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-19 13:29 Question about Cygwin's select() Ken Brown 2011-10-19 14:49 ` Corinna Vinschen 2011-10-19 15:29 ` Ken Brown 2011-10-19 16:22 ` Christopher Faylor 2011-10-19 17:32 ` Ken Brown 2011-10-19 20:15 ` Ken Brown 2011-10-19 20:31 ` Jon Clugston 2011-10-20 2:39 ` Ken Brown 2011-10-20 12:14 ` Ken Brown 2011-10-21 9:45 ` Corinna Vinschen 2011-10-21 14:27 ` Ken Brown 2011-10-21 15:45 ` Jon Clugston 2011-10-21 20:03 ` Ken Brown 2011-10-22 9:55 ` Ken Brown 2011-10-22 20:42 ` Ken Brown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).