Re: fork fails after nmap with hint address in an unmapped memory region

[Brian Inglis <Brian dot Inglis at SystematicSw dot ab dot ca>]

On 2017-12-09 15:51, Jon Turney wrote:
> On 09/12/2017 18:29, Brian Inglis wrote:
>> On 2017-12-09 08:53, Stéphane Mbape via cygwin wrote:
>>> Le 09/12/2017 à 16:48, Andrey Repin a écrit :
>>>>> While embeding luajit in a c  program, I found myself unable to fork
>>>>> processes.
>>>>> Investigations prove that it was related to nmap.
>>>>> To be accurate, calling nmap with hint address in a unmapped memory
>>>>> region will cause all forks to fail with
>>>>> "fixup_mmaps_after_fork: ReadProcessMemory failed for MAP_PRIVATE
>>>>> address 0x6FFFFFE0000, Win32 error 299"
>>>>> There is a sample code below.
>>>> You forgot to mention Cygwin version you're using, and please provide the
>>>> sample as an attach to save people the copy-pasting issues.
>>> Cygwin version: 2.9.0
>>> OS: Windows 10
>>> Arch: 64bit
>>> The sample was also attached.
>>
>> Confirmed reproducible; addr2line does not give anything useful from the
>> stackdump, but included raw stackdump below, in case it gives hints.
> 
> If you're going to use addr2line to interpret a .stackdump file, I'm afraid
> you're just supposed to know that the cygwin1.dll has an ImageBase of
> 0x0000000180040000 on x86_64

Who came up with that magic number 6G256K and why - would a round 7/8G not do?

>> $ more mmap_fork_stc.exe.stackdump
>> Stack trace:
>> Frame        Function    Args
>> 000005FF3A0  0018005CD8E (0018021AE80, 0018021AC46, 00000008000, 000005FB010)
>> 000005FF3A0  001800465F9 (000005FDDE0, 000005FF3A0, 001800B2D10, 00000000000)
>> 000005FF3A0  00180046632 (00000000000, 000005FBE28, 00000008000, 00100402068)
>> 000005FF3A0  00180046B84 (0007FFE0385, 000005FDDE0, 001800B2D10, 00000000000)
>> 000005FF3A0  00180048040 (00000000000, 00000000000, 00000000000, 00000000000)
>> 000005FF3A0  001800B2EDB (00000000000, 00000000000, 00000000000, 00000000000)
>> 000005FF620  7FFF7777485F (00180040000, 00000000001, 00000240022, 000006D20C8)
>> 000005FF620  7FFF7779D762 (7FFF77797900, 000006D2701, 7FFF774A27BA, 000006D2F10)
>> 000005FF620  7FFF7779D5AB (000006D2720, 000005FF5D0, 00000000003, 0000032E000)
>> 000005FF620  7FFF7779D5D1 (00000000003, 000005FF629, 00000000003, 00000000000)
>> 00000000000  7FFF777E1D31 (00000000000, 00000000000, 00000000001, 00000000000)
>> 00000000000  7FFF7781A1FC (00000000000, 00000000000, 0000032E000, 00000000000)
>> 00000000000  7FFF777C9B1B (00000000000, 00000000000, 00000000000, 00000000000)
>> 00000000000  7FFF777C9ACE (00000000000, 00000000000, 00000000000, 00000000000)
>> End of stack trace
> 
> Sator Arepo Tenet Opera Rotas! [1]
> 
> 0x000000018005cd8e    cygwin_stackdump                 exceptions.cc:456
> 0x00000001800465f9    vapi_fatal                        dcrt0.cc:1296
> 0x0000000180046632    api_fatal                         dcrt0.cc:1305
> 0x0000000180046b84    child_info_fork::handle_fork()    dcrt0.cc:634
> 0x0000000180048040    dll_crt0_0()                      dcrt0.cc:777
> 0x00000001800b2edb    dll_entry                         init.cc:102
> 
> [1] https://cygwin.com/ml/cygwin/2015-08/msg00311.html

Happen to have an old stackdump script around from 2013 without that magic.
Neither helps more than the original error message, which tells us that there is
a fork problem with the mmaps: either the mmap allocator is saving the wrong
address, as it appears on a segment boundary, or something else in that
structure is not being saved correctly for anonymous private mmap fixup, as
changing the hinted address to a segment boundary keeps the magic smoke in.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple