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
hypothesis:
sysdep.c:
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)
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);
switch (waitret)
{
case WAIT_OBJECT_0:
break;
case WAIT_TIMEOUT:
set_errno (EAGAIN);
len = (size_t) -1;
return;
default:
set_errno (EINTR);
len = (size_t) -1;
return;
}
Takashi, is EINTR really the appropriate errno in the default case? Isn't
cygwait supposed to handle signals?
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
