Another pipe-related problem?

[Ken Brown]

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