This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH draft 0/6] Remove the fhandler_base_overlapped class
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:
Author: Michael Haubenwallner <email@example.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
There will be a long delay while emacs tries to fork, followed eventually by an
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.