Another pipe-related problem?
Tue Nov 9 14:11:28 GMT 2021
On 11/9/2021 5:55 AM, Henry S. Thompson wrote:
> Ken Brown via Cygwin writes:
>> On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote:
>>> Running on Windows-10 21H1
>>> With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs:
>>> #6 0x000000018013ffcc in read (fd=3, ptr=0xffff0bc0, len=<optimized out>)
>>> at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/dtable.h:64
>>> #7 0x000000018018e88b in _sigfe () at sigfe.s:35
>>> #8 0x000000010066a11d in retry_read_1 (fildes=3, buf=0xffff0bc0, nbyte=128,
>>> allow_quit=0) at sysdep.c:2425
>>> #9 0x000000010066a171 in retry_read (fildes=3, buf=0xffff0bc0, nbyte=128)
>>> at sysdep.c:2437
>>> #10 0x0000000100494d86 in drain_signal_event_pipe () at event-unixoid.c:159
>>> #11 0x000000010056d1dc in mswindows_need_event (badly_p=1) at event-msw.c:1432
>>> This is an old executable, has worked since 2015 (!), but recompiling
>>> didn't help. Reverting to 3.2 lets it run again.
>> This backtrace doesn't match the source of Cygwin's XEmacs package
>> (which exists on 32-bit Cygwin only), so I assume you built this
>> yourself, using a different version of XEmacs. Cygwin's XEmacs
>> doesn't hang for me.
> Thanks for looking in to this!
> And you're right, it's a local build. I was responsible for producing
> the 64-bit XEmacs back in 2015, but could never get a Visual Studio
> build to work at that time, so it was never released.
>> Please provide build instructions for the version you compiled.
> As you may know, the XEmacs situation is complicated. The old source
> repo (bitbucket.org/xemacs) no longer exists. There's a fork that's
> still being maintained, but it's not widely publicised. That's the
> one I'm working with -- are you aware of this.
I was aware that the bitbucket repo didn't exist, because I tried to get the
sources there. But I didn't know about the fork. Please point me to it, or
just make a tarball available to me somehow.
> Here are the immediate contexts from the sources for the xemacs
> sources in the above backtrace, might be enough to check your
> retry_read_1 (int fildes, void *buf, size_t nbyte, int allow_quit)
> ssize_t rtnval;
> while ((rtnval = read (fildes, buf, nbyte)) == -1
> && (errno == EINTR)) <<<<<<<<<<<<<<<<<<<<
> if (allow_quit)
> return rtnval;
I'll have to reproduce the hang myself in order to test this (or maybe you could
test it), but I now have a new guess: If the read call above keeps failing with
EINTR, then we're in an infinite loop. This could happen because of the
following code in fhandler_pipe::raw_read:
DWORD waitret = cygwait (read_mtx, timeout);
len = (size_t) -1;
len = (size_t) -1;
Takashi, is EINTR really the appropriate errno in the default case? Isn't
cygwait supposed to handle signals?
More information about the Cygwin