Mail Archives: cygwin/2011/10/19/13:32:55
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
- Raw text -