Re: [PATCH draft 0/6] Remove the fhandler_base_overlapped class

[Ken Brown <kbrown at cornell dot edu>]

On 6/7/2019 5:43 PM, Ken Brown wrote:
> On 6/7/2019 3:13 PM, Ken Brown wrote:
>> On 6/7/2019 2:31 PM, Achim Gratz wrote:
>>> Ken Brown writes:
>>>> I think I've found the problem.  I was mishandling signals that arrived during a
>>>> read.  But after I fix that, there's still one nagging issue involving timerfd
>>>> code.  I'll write to the main list with details.  I *think* it's a timerfd bug,
>>>> but it's puzzling that I only see it when testing my new pipe implementation.
>>>
>>> Anything triggering a race or deadlock will depend on so many other
>>> things that it really is no surprise to see seemingly unrelated changes
>>> making the bug appear or disappear.  There are certainly races left in
>>> Cygwin, I see them from time to time in various Perl modules, just never
>>> reproducible enough to give anyone an idea of where to look.
>>
>> That makes sense.
>>
>> In the meantime, I've already discovered another problem, within an hour of
>> posting my claim that everything was working fine: If I start emacs-X11 with
>> cygserver running, I can't fork any subprocesses within emacs.  I get
>>
>> 0 [main] emacs 2689 dofork: child 2693 - died waiting for dll loading, errno 11
>>
>> Back to the drawing board....  I've never looked at the cygserver code, but
>> maybe it will turn out to be something easy.
> 
> Good news (for me): This isn't related to my pipe code.  The same problem occurs
> if I build the master branch.  I'll bisect when I get a chance (probably
> tomorrow).  In the meantime, all I can say is that strace shows a
> STATUS_ACCESS_VIOLATION at shm.cc:125.

A bisection shows that the problem starts with the following commit:

commit f03ea8e1c57bd5cea83f6cd47fa02870bdfeb1c5
Author: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
Date:   Thu May 2 12:12:44 2019 +0200

     Cygwin: fork: Remember child not before success.

     Do not remember the child before it was successfully initialized, or we
     would need more sophisticated cleanup on child initialization failure,
     like cleaning up the process table and suppressing SIGCHILD delivery
     with multiple threads ("waitproc") involved.  Compared to that, the
     potential slowdown due to an extra yield () call should be negligible.

I haven't tried to make an STC, but here's what I do to reproduce the problem:

1. Start cygserver.

2. Start the X server (e.g., by using the Start Menu shortcut created by the 
xinit postinstall script).

3. Start an xterm.

4. Run 'emacs-X11 -Q' in the xterm window.

5. Do anything that causes emacs to try to fork (e.g., 'C-x d' to list the 
current directory).

There will be a long delay while emacs tries to fork, followed eventually by an 
error message.

strace and addr2line show that there's a crash at shm.cc:125.

I hope this is enough information for someone to track down the problem.  If 
not, I could probably make an STC that doesn't involve emacs.

Ken