Re: fixup_mmaps_after_fork failure with cygwin-3.0.0
- Date: Sun, 17 Feb 2019 14:56:49 +0000
- From: Ken Brown <kbrown@xxxxxxxxxxx>
- Subject: Re: fixup_mmaps_after_fork failure with cygwin-3.0.0
On 2/17/2019 4:13 AM, Corinna Vinschen wrote:
> On Feb 17 10:08, Corinna Vinschen wrote:
>> On Feb 17 00:11, Ken Brown wrote:
>>> I'm getting a lot of errors like this when building emacs from its git repo:
>>> EMACSLOADPATH= '../src/emacs.exe' -batch --no-site-file --no-site-lisp --eval
>>> '(setq load-prefer-newer t)' -f batch-byte-compile ../../master/lisp/finder.el
>>> 1 [main] emacs 26848 fixup_mmaps_after_fork: VirtualProtectEx failed for
>>> MAP_PRIVATE address 0x6FFFFCD0000, Win32 error 5
>>> 190 [main] emacs 26848 C:\Users\kbrown\src\emacs\x86_64\src\emacs.exe: ***
>>> fatal error in forked process - recreate_mmaps_after_fork_failed
>>> 619 [main] emacs 26848 cygwin_exception::open_stackdumpfile: Dumping stack
>>> trace to emacs.exe.stackdump
>>> 1 [main] emacs 27052 fork: child -1 - forked process 26848 died
>>> unexpectedly, retry 0, exit code 0x100, errno 11
>> Weird. I built at least gawk and openssh with 3.0 already and I
>> didn't notice this problem.
>>> A bisection points to the following as the first bad commit:
>>> commit 69cc7a068656b5c6ef07ca079a213f801e02e650
>>> Author: Corinna Vinschen <corinna@xxxxxxxxxxx>
>>> Date: Sun Jan 27 13:15:15 2019 +0100
>>> Cygwin: fork: restrict parent handle perms and drop handle after use
>>> I'll try to do some debugging and/or provide further information tomorrow, but I
>>> thought I'd start with this preliminary report.
>> That would be nice. It's not clear to me which permission is missing.
>> The first part of the patch has been reverted in 3.0.0, so
>> child_info_spawn::get_parent_handle opens the parent with
>> PROCESS_VM_READ again. The second patch has been reworked as well,m
>> the current perms are
>> PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ | SYNCHRONIZE
>> If I may place a bet, please try to replace
>> PROCESS_QUERY_LIMITED_INFORMATION with PROCESS_QUERY_INFORMATION
That didn't change anything. Just to make sure I understood correctly, here's
what I tried:
@@ -814,7 +814,7 @@ child_info::child_info (unsigned in_cb, child_info_types chtype,
allow the child to copy cygheap etc. from the parent to itself. If
we're forking, we also need handle duplicate access. */
parent = NULL;
- DWORD perms = PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ
+ DWORD perms = PROCESS_QUERY_INFORMATION | PROCESS_VM_READ
if (type == _CH_FORK)
> On second thought, an even better candidate may be PROCESS_VM_OPERATION.
That's even worse. With that change, simply invoking 'make' leads to the same
>> What OS is that? W7?
W10 1803 with WSL installed.
I'll keep looking at this, but let me know if you have further ideas. It would
be nice if I could come up with a simple test case, but at the moment all I have
is, "clone the emacs git repo and try to build".