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
