* Random "child_info_fork::abort:" @ 2016-10-12 5:59 Evgeny Grin 2016-10-12 8:36 ` Brian Inglis 0 siblings, 1 reply; 13+ messages in thread From: Evgeny Grin @ 2016-10-12 5:59 UTC (permalink / raw) To: cygwin Hi! I'm using Windows Insider (slow ring, prerelease). After recent update to build 14931, cygwin keeps randomly fail on fork. This happens not every fork, but frequent enough. Simplest way to trigger it is to run mandb. At variable delay I got something like child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to different address: parent(0x3FEAB0000) != child(0x1C0000) Dll name and child address may vary. I updated cygwin to latest version, but problem remains. Exactly the same problem with Msys2, but additionally from time to time I got different error: *** fatal error - cygheap base mismatch detected - 0x1802FE408/0x106E408. This problem is probably due to.... I set variable CYGWIN=detect_bloda, but nothing is detected. What else could I check? Versions: $ uname -srvmo CYGWIN_NT-10.0 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin $ cat /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows\ NT/CurrentVersion/CurrentBuildNumber 14931 -- Best Wishes, Evgeny Grin -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-12 5:59 Random "child_info_fork::abort:" Evgeny Grin @ 2016-10-12 8:36 ` Brian Inglis 2016-10-12 12:00 ` Evgeny Grin 0 siblings, 1 reply; 13+ messages in thread From: Brian Inglis @ 2016-10-12 8:36 UTC (permalink / raw) To: cygwin On 2016-10-11 15:32, Evgeny Grin wrote: > I'm using Windows Insider (slow ring, prerelease). After recent update > to build 14931, cygwin keeps randomly fail on fork. This happens not > every fork, but frequent enough. Simplest way to trigger it is to run mandb. > At variable delay I got something like > child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to > different address: parent(0x3FEAB0000) != child(0x1C0000) > Dll name and child address may vary. > I updated cygwin to latest version, but problem remains. > Exactly the same problem with Msys2, but additionally from time to time > I got different error: > *** fatal error - cygheap base mismatch detected - 0x1802FE408/0x106E408. > This problem is probably due to.... > I set variable CYGWIN=detect_bloda, but nothing is detected. > What else could I check? > Versions: > $ uname -srvmo > CYGWIN_NT-10.0 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin > $ cat /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows\ > NT/CurrentVersion/CurrentBuildNumber > 14931 Run rebase -is to check for DLL conflicts. After the update did you run "rebase-trigger full" and setup, with NO Cygwin processes running, to remap the system DLLs and rebase the Cygwin DLLs? It's likely the Insider debug builds dynamically enable/disable features and functions or run alternate system DLLs which gather info by acting as BLODAs. MS can mess around with your systems to enable new stuff (possibly in different combinations) and see which systems they cause problems on. Hopefully they can also dynamically revert new releases causing problems. Your systems are the canaries for their Continuous Delivery QA. Make sure you continously back up any work on those systems and don't ignore warnings, especially build expiries (you are meant to be allowed 3 reboots after expiry before the buildrefuses to boot!) -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-12 8:36 ` Brian Inglis @ 2016-10-12 12:00 ` Evgeny Grin 2016-10-13 4:43 ` Evgeny Grin 0 siblings, 1 reply; 13+ messages in thread From: Evgeny Grin @ 2016-10-12 12:00 UTC (permalink / raw) To: cygwin On 12.10.2016 8:59, Brian Inglis wrote: > On 2016-10-11 15:32, Evgeny Grin wrote: >> I'm using Windows Insider (slow ring, prerelease). After recent update >> to build 14931, cygwin keeps randomly fail on fork. This happens not >> every fork, but frequent enough. Simplest way to trigger it is to run >> mandb. >> At variable delay I got something like >> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to >> different address: parent(0x3FEAB0000) != child(0x1C0000) >> Dll name and child address may vary. >> I updated cygwin to latest version, but problem remains. >> Exactly the same problem with Msys2, but additionally from time to time >> I got different error: >> *** fatal error - cygheap base mismatch detected - 0x1802FE408/0x106E408. >> This problem is probably due to.... > >> I set variable CYGWIN=detect_bloda, but nothing is detected. >> What else could I check? > > Run rebase -is to check for DLL conflicts. > After the update did you run "rebase-trigger full" and setup, > with NO Cygwin processes running, to remap the system DLLs > and rebase the Cygwin DLLs? Done. No conflicts. Setup run fine, problem is not solved. Observation: Cygwin errors appears more often than Msys2 errors. Even got initial loading on incorrect address: child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to different address: parent(0x190000) != child(0x3FB700000) > It's likely the Insider debug builds dynamically enable/disable > features and functions or run alternate system DLLs which gather > info by acting as BLODAs. > MS can mess around with your systems to enable new stuff (possibly > in different combinations) and see which systems they cause problems > on. > Hopefully they can also dynamically revert new releases causing > problems. > Your systems are the canaries for their Continuous Delivery QA. > > Make sure you continously back up any work on those systems and > don't ignore warnings, especially build expiries (you are meant > to be allowed 3 reboots after expiry before the buildrefuses > to boot!) Thanks! Not sure that situation is just "test" or "temporary". I'm using prerelease track so this can go to release. -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-12 12:00 ` Evgeny Grin @ 2016-10-13 4:43 ` Evgeny Grin 2016-10-13 12:00 ` Evgeny Grin 0 siblings, 1 reply; 13+ messages in thread From: Evgeny Grin @ 2016-10-13 4:43 UTC (permalink / raw) To: cygwin On 12.10.2016 13:59, Evgeny Grin wrote: > On 12.10.2016 8:59, Brian Inglis wrote: >> On 2016-10-11 15:32, Evgeny Grin wrote: >>> I'm using Windows Insider (slow ring, prerelease). After recent update >>> to build 14931, cygwin keeps randomly fail on fork. This happens not >>> every fork, but frequent enough. Simplest way to trigger it is to run >>> mandb. >>> At variable delay I got something like >>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to >>> different address: parent(0x3FEAB0000) != child(0x1C0000) >>> Dll name and child address may vary. >>> I updated cygwin to latest version, but problem remains. >>> Exactly the same problem with Msys2, but additionally from time to time >>> I got different error: >>> *** fatal error - cygheap base mismatch detected - 0x1802FE408/0x106E408. >>> This problem is probably due to.... >> >>> I set variable CYGWIN=detect_bloda, but nothing is detected. >>> What else could I check? >> >> Run rebase -is to check for DLL conflicts. >> After the update did you run "rebase-trigger full" and setup, >> with NO Cygwin processes running, to remap the system DLLs >> and rebase the Cygwin DLLs? > > Done. No conflicts. > Setup run fine, problem is not solved. > > Observation: Cygwin errors appears more often than Msys2 errors. > Even got initial loading on incorrect address: > > child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to > different address: parent(0x190000) != child(0x3FB700000) > >> It's likely the Insider debug builds dynamically enable/disable >> features and functions or run alternate system DLLs which gather >> info by acting as BLODAs. >> MS can mess around with your systems to enable new stuff (possibly >> in different combinations) and see which systems they cause problems >> on. >> Hopefully they can also dynamically revert new releases causing >> problems. >> Your systems are the canaries for their Continuous Delivery QA. >> >> Make sure you continously back up any work on those systems and >> don't ignore warnings, especially build expiries (you are meant >> to be allowed 3 reboots after expiry before the buildrefuses >> to boot!) > > Thanks! > Not sure that situation is just "test" or "temporary". I'm using > prerelease track so this can go to release. Additionally tested under VM. Clear install of Windows 10 x64 14931 (US English), VM guest tools and Cygwin x64. First run of man-db - same error. Need new workarounds? Seems that will be in all new builds. -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-13 4:43 ` Evgeny Grin @ 2016-10-13 12:00 ` Evgeny Grin 2016-10-13 12:31 ` Marco Atzeri 2016-10-13 16:29 ` Evgeny Grin 0 siblings, 2 replies; 13+ messages in thread From: Evgeny Grin @ 2016-10-13 12:00 UTC (permalink / raw) To: cygwin On 12.10.2016 21:45, Evgeny Grin wrote: > On 12.10.2016 13:59, Evgeny Grin wrote: >> On 12.10.2016 8:59, Brian Inglis wrote: >>> On 2016-10-11 15:32, Evgeny Grin wrote: >>>> I'm using Windows Insider (slow ring, prerelease). After recent update >>>> to build 14931, cygwin keeps randomly fail on fork. This happens not >>>> every fork, but frequent enough. Simplest way to trigger it is to run >>>> mandb. >>>> At variable delay I got something like >>>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to >>>> different address: parent(0x3FEAB0000) != child(0x1C0000) >>>> Dll name and child address may vary. >>>> I updated cygwin to latest version, but problem remains. >>>> Exactly the same problem with Msys2, but additionally from time to time >>>> I got different error: >>>> *** fatal error - cygheap base mismatch detected - 0x1802FE408/0x106E408. >>>> This problem is probably due to.... >>> >>>> I set variable CYGWIN=detect_bloda, but nothing is detected. >>>> What else could I check? >>> >>> Run rebase -is to check for DLL conflicts. >>> After the update did you run "rebase-trigger full" and setup, >>> with NO Cygwin processes running, to remap the system DLLs >>> and rebase the Cygwin DLLs? >> >> Done. No conflicts. >> Setup run fine, problem is not solved. >> >> Observation: Cygwin errors appears more often than Msys2 errors. >> Even got initial loading on incorrect address: >> >> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to >> different address: parent(0x190000) != child(0x3FB700000) >> >>> It's likely the Insider debug builds dynamically enable/disable >>> features and functions or run alternate system DLLs which gather >>> info by acting as BLODAs. >>> MS can mess around with your systems to enable new stuff (possibly >>> in different combinations) and see which systems they cause problems >>> on. >>> Hopefully they can also dynamically revert new releases causing >>> problems. >>> Your systems are the canaries for their Continuous Delivery QA. >>> >>> Make sure you continously back up any work on those systems and >>> don't ignore warnings, especially build expiries (you are meant >>> to be allowed 3 reboots after expiry before the buildrefuses >>> to boot!) >> >> Thanks! >> Not sure that situation is just "test" or "temporary". I'm using >> prerelease track so this can go to release. > > Additionally tested under VM. > Clear install of Windows 10 x64 14931 (US English), VM guest tools and > Cygwin x64. First run of man-db - same error. > Need new workarounds? > Seems that will be in all new builds. Same happens with new Windows build 14942. Both Cygwin and Msys2 is not usable anymore. MS is pushing us to "Ubuntu on Windows"? -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-13 12:00 ` Evgeny Grin @ 2016-10-13 12:31 ` Marco Atzeri 2016-10-13 13:12 ` Eliot Moss 2016-10-13 16:29 ` Evgeny Grin 1 sibling, 1 reply; 13+ messages in thread From: Marco Atzeri @ 2016-10-13 12:31 UTC (permalink / raw) To: cygwin On 13/10/2016 09:11, Evgeny Grin wrote: >> >> Additionally tested under VM. >> Clear install of Windows 10 x64 14931 (US English), VM guest tools and >> Cygwin x64. First run of man-db - same error. >> Need new workarounds? >> Seems that will be in all new builds. > > Same happens with new Windows build 14942. > Both Cygwin and Msys2 is not usable anymore. > > MS is pushing us to "Ubuntu on Windows"? > Interesting. Are we back to the old tactics ? https://en.wikipedia.org/wiki/AARD_code Regards Marco -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-13 12:31 ` Marco Atzeri @ 2016-10-13 13:12 ` Eliot Moss 2016-10-13 14:35 ` Brian Inglis 0 siblings, 1 reply; 13+ messages in thread From: Eliot Moss @ 2016-10-13 13:12 UTC (permalink / raw) To: cygwin On 10/13/2016 8:00 AM, Marco Atzeri wrote: > On 13/10/2016 09:11, Evgeny Grin wrote: >> MS is pushing us to "Ubuntu on Windows"? >> > > Interesting. Are we back to the old tactics ? > > https://en.wikipedia.org/wiki/AARD_code I don't see the motivation. We still buy Windows. Do you think they'll charge extra for UoW? Regards - Eliot Moss -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-13 13:12 ` Eliot Moss @ 2016-10-13 14:35 ` Brian Inglis 0 siblings, 0 replies; 13+ messages in thread From: Brian Inglis @ 2016-10-13 14:35 UTC (permalink / raw) To: cygwin On 2016-10-13 06:31, Eliot Moss wrote: > On 10/13/2016 8:00 AM, Marco Atzeri wrote: >> On 13/10/2016 09:11, Evgeny Grin wrote: >>> MS is pushing us to "Ubuntu on Windows"? >> Interesting. Are we back to the old tactics ? >> https://en.wikipedia.org/wiki/AARD_code > I don't see the motivation. We still buy Windows. > Do you think they'll charge extra for UoW? Nope - they always need a POSIX subsystem available in some form in order to satisy US Fed government requirements for mandatory POSIX compatibility on all systems contract bids, even if few will ever use that capability on their desktops or servers. -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-13 12:00 ` Evgeny Grin 2016-10-13 12:31 ` Marco Atzeri @ 2016-10-13 16:29 ` Evgeny Grin 2016-10-13 17:56 ` Evgeny Grin 1 sibling, 1 reply; 13+ messages in thread From: Evgeny Grin @ 2016-10-13 16:29 UTC (permalink / raw) To: cygwin On 13.10.2016 10:11, Evgeny Grin wrote: > On 12.10.2016 21:45, Evgeny Grin wrote: >> On 12.10.2016 13:59, Evgeny Grin wrote: >>> On 12.10.2016 8:59, Brian Inglis wrote: >>>> On 2016-10-11 15:32, Evgeny Grin wrote: >>>>> I'm using Windows Insider (slow ring, prerelease). After recent update >>>>> to build 14931, cygwin keeps randomly fail on fork. This happens not >>>>> every fork, but frequent enough. Simplest way to trigger it is to run >>>>> mandb. >>>>> At variable delay I got something like >>>>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to >>>>> different address: parent(0x3FEAB0000) != child(0x1C0000) >>>>> Dll name and child address may vary. >>>>> I updated cygwin to latest version, but problem remains. >>>>> Exactly the same problem with Msys2, but additionally from time to time >>>>> I got different error: >>>>> *** fatal error - cygheap base mismatch detected - 0x1802FE408/0x106E408. >>>>> This problem is probably due to.... >>>> >>>>> I set variable CYGWIN=detect_bloda, but nothing is detected. >>>>> What else could I check? >>>> >>>> Run rebase -is to check for DLL conflicts. >>>> After the update did you run "rebase-trigger full" and setup, >>>> with NO Cygwin processes running, to remap the system DLLs >>>> and rebase the Cygwin DLLs? >>> >>> Done. No conflicts. >>> Setup run fine, problem is not solved. >>> >>> Observation: Cygwin errors appears more often than Msys2 errors. >>> Even got initial loading on incorrect address: >>> >>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to >>> different address: parent(0x190000) != child(0x3FB700000) >>> >>>> It's likely the Insider debug builds dynamically enable/disable >>>> features and functions or run alternate system DLLs which gather >>>> info by acting as BLODAs. >>>> MS can mess around with your systems to enable new stuff (possibly >>>> in different combinations) and see which systems they cause problems >>>> on. >>>> Hopefully they can also dynamically revert new releases causing >>>> problems. >>>> Your systems are the canaries for their Continuous Delivery QA. >>>> >>>> Make sure you continously back up any work on those systems and >>>> don't ignore warnings, especially build expiries (you are meant >>>> to be allowed 3 reboots after expiry before the buildrefuses >>>> to boot!) >>> >>> Thanks! >>> Not sure that situation is just "test" or "temporary". I'm using >>> prerelease track so this can go to release. >> >> Additionally tested under VM. >> Clear install of Windows 10 x64 14931 (US English), VM guest tools and >> Cygwin x64. First run of man-db - same error. >> Need new workarounds? >> Seems that will be in all new builds. > > Same happens with new Windows build 14942. > Both Cygwin and Msys2 is not usable anymore. > > MS is pushing us to "Ubuntu on Windows"? > When trying to actively use cygwin, got same (as in Msys2) errors: *** fatal error - cygheap base mismatch detected - 0x180302408/0x1082408. Is it because of cygwin.dll loaded on incorrect address? -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-13 16:29 ` Evgeny Grin @ 2016-10-13 17:56 ` Evgeny Grin 2016-10-13 21:05 ` Evgeny Grin 0 siblings, 1 reply; 13+ messages in thread From: Evgeny Grin @ 2016-10-13 17:56 UTC (permalink / raw) To: cygwin On 13.10.2016 18:24, Evgeny Grin wrote: > On 13.10.2016 10:11, Evgeny Grin wrote: >> On 12.10.2016 21:45, Evgeny Grin wrote: >>> On 12.10.2016 13:59, Evgeny Grin wrote: >>>> On 12.10.2016 8:59, Brian Inglis wrote: >>>>> On 2016-10-11 15:32, Evgeny Grin wrote: >>>>>> I'm using Windows Insider (slow ring, prerelease). After recent update >>>>>> to build 14931, cygwin keeps randomly fail on fork. This happens not >>>>>> every fork, but frequent enough. Simplest way to trigger it is to run >>>>>> mandb. >>>>>> At variable delay I got something like >>>>>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to >>>>>> different address: parent(0x3FEAB0000) != child(0x1C0000) >>>>>> Dll name and child address may vary. >>>>>> I updated cygwin to latest version, but problem remains. >>>>>> Exactly the same problem with Msys2, but additionally from time to time >>>>>> I got different error: >>>>>> *** fatal error - cygheap base mismatch detected - 0x1802FE408/0x106E408. >>>>>> This problem is probably due to.... >>>>> >>>>>> I set variable CYGWIN=detect_bloda, but nothing is detected. >>>>>> What else could I check? >>>>> >>>>> Run rebase -is to check for DLL conflicts. >>>>> After the update did you run "rebase-trigger full" and setup, >>>>> with NO Cygwin processes running, to remap the system DLLs >>>>> and rebase the Cygwin DLLs? >>>> >>>> Done. No conflicts. >>>> Setup run fine, problem is not solved. >>>> >>>> Observation: Cygwin errors appears more often than Msys2 errors. >>>> Even got initial loading on incorrect address: >>>> >>>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to >>>> different address: parent(0x190000) != child(0x3FB700000) >>>> >>>>> It's likely the Insider debug builds dynamically enable/disable >>>>> features and functions or run alternate system DLLs which gather >>>>> info by acting as BLODAs. >>>>> MS can mess around with your systems to enable new stuff (possibly >>>>> in different combinations) and see which systems they cause problems >>>>> on. >>>>> Hopefully they can also dynamically revert new releases causing >>>>> problems. >>>>> Your systems are the canaries for their Continuous Delivery QA. >>>>> >>>>> Make sure you continously back up any work on those systems and >>>>> don't ignore warnings, especially build expiries (you are meant >>>>> to be allowed 3 reboots after expiry before the buildrefuses >>>>> to boot!) >>>> >>>> Thanks! >>>> Not sure that situation is just "test" or "temporary". I'm using >>>> prerelease track so this can go to release. >>> >>> Additionally tested under VM. >>> Clear install of Windows 10 x64 14931 (US English), VM guest tools and >>> Cygwin x64. First run of man-db - same error. >>> Need new workarounds? >>> Seems that will be in all new builds. >> >> Same happens with new Windows build 14942. >> Both Cygwin and Msys2 is not usable anymore. >> >> MS is pushing us to "Ubuntu on Windows"? >> > > When trying to actively use cygwin, got same (as in Msys2) errors: > > *** fatal error - cygheap base mismatch detected - 0x180302408/0x1082408. > > Is it because of cygwin.dll loaded on incorrect address? > What I got from strace (typical output): 649705 [main] mandb 6288 child_info::sync: n 2, waiting for subproc_ready(0x280) and child process(0x1CC) 6358 [main] mandb 7888 child_info_fork::abort: T:\cygwin64\bin\cyggdbm-4.dll: Loaded to different address: parent(0x1FFFC510000) != child(0x150000) --- Process 7888 created --- Process 7888 loaded C:\Windows\System32\ntdll.dll at 00007FFE2FF70000 --- Process 7888 loaded C:\Windows\System32\kernel32.dll at 00007FFE2D600000 --- Process 7888 loaded C:\Windows\System32\KernelBase.dll at 00007FFE2C730000 --- Process 7888 thread 912 created --- Process 7888 thread 10792 created --- Process 7888 loaded T:\cygwin64\bin\cygmandb-2-7-5.dll at 000001FFFB8F0000 --- Process 7888 loaded T:\cygwin64\bin\cygwin1.dll at 0000000180040000 --- Process 7888 loaded T:\cygwin64\bin\cygintl-8.dll at 00000003FBB90000 --- Process 7888 thread 14024 created --- Process 7888 loaded T:\cygwin64\bin\cygiconv-2.dll at 00000003FBBF0000 --- Process 7888 loaded T:\cygwin64\bin\cygpipeline-1.dll at 000001FFFB470000 --- Process 7888 loaded T:\cygwin64\bin\cygman-2-7-5.dll at 000001FFFB900000 --- Process 7888 loaded T:\cygwin64\bin\cyggdbm-4.dll at 0000000000150000 --- Process 7888 loaded T:\cygwin64\bin\cygman-2-7-5.dll at 0000000000170000 --- Process 7888 unloaded DLL at 0000000000170000 --- Process 7888 loaded T:\cygwin64\bin\cygz.dll at 000001FFFACF0000 --- Process 7888 loaded T:\cygwin64\bin\cyggdbm-4.dll at 000001FFFC510000 --- Process 7888 unloaded DLL at 000001FFFC510000 6358 [main] mandb 7888 child_info_fork::abort: T:\cygwin64\bin\cyggdbm-4.dll: Loaded to different address: parent(0x1FFFC510000) != child(0x150000) --- Process 7888 thread 14024 exited with status 0x800000 --- Process 7888 thread 10144 exited with status 0x800000 --- Process 7888 thread 10792 exited with status 0x800000 --- Process 7888 exited with status 0x800000 663649 [main] mandb 6288 child_info::sync: pid 7888, WFMO returned 1, exit_code 0x800000, res 0 663743 [main] mandb 6288 sig_send: sendsig 0xD8, pid 6288, signal -73, its_me 1 663771 [main] mandb 6288 sig_send: wakeup 0x2EC 663800 [main] mandb 6288 sig_send: Waiting for pack.wakeup 0x2EC 663840 [sig] mandb 6288 wait_sig: signalling pack.wakeup 0x2EC 663886 [main] mandb 6288 sig_send: returning 0x0 from sending signal -73 mandb: fork failed: Resource temporarily unavailable The cyggdbm-4.dll is loaded two times: at 0x150000 and at 0x1FFFC510000, but for some reason unloaded from 0x1FFFC510000. This looks like a bug in cygwin. -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-13 17:56 ` Evgeny Grin @ 2016-10-13 21:05 ` Evgeny Grin 2016-10-15 10:28 ` Tony Kelman 0 siblings, 1 reply; 13+ messages in thread From: Evgeny Grin @ 2016-10-13 21:05 UTC (permalink / raw) To: cygwin On 13.10.2016 19:58, Evgeny Grin wrote: > On 13.10.2016 18:24, Evgeny Grin wrote: > > What I got from strace (typical output): > > 649705 [main] mandb 6288 child_info::sync: n 2, waiting for > subproc_ready(0x280) and child process(0x1CC) > 6358 [main] mandb 7888 child_info_fork::abort: > T:\cygwin64\bin\cyggdbm-4.dll: Loaded to different address: > parent(0x1FFFC510000) != child(0x150000) > --- Process 7888 created > --- Process 7888 loaded C:\Windows\System32\ntdll.dll at 00007FFE2FF70000 > --- Process 7888 loaded C:\Windows\System32\kernel32.dll at 00007FFE2D600000 > --- Process 7888 loaded C:\Windows\System32\KernelBase.dll at > 00007FFE2C730000 > --- Process 7888 thread 912 created > --- Process 7888 thread 10792 created > --- Process 7888 loaded T:\cygwin64\bin\cygmandb-2-7-5.dll at > 000001FFFB8F0000 > --- Process 7888 loaded T:\cygwin64\bin\cygwin1.dll at 0000000180040000 > --- Process 7888 loaded T:\cygwin64\bin\cygintl-8.dll at 00000003FBB90000 > --- Process 7888 thread 14024 created > --- Process 7888 loaded T:\cygwin64\bin\cygiconv-2.dll at 00000003FBBF0000 > --- Process 7888 loaded T:\cygwin64\bin\cygpipeline-1.dll at > 000001FFFB470000 > --- Process 7888 loaded T:\cygwin64\bin\cygman-2-7-5.dll at 000001FFFB900000 > --- Process 7888 loaded T:\cygwin64\bin\cyggdbm-4.dll at 0000000000150000 > --- Process 7888 loaded T:\cygwin64\bin\cygman-2-7-5.dll at 0000000000170000 > --- Process 7888 unloaded DLL at 0000000000170000 > --- Process 7888 loaded T:\cygwin64\bin\cygz.dll at 000001FFFACF0000 > --- Process 7888 loaded T:\cygwin64\bin\cyggdbm-4.dll at 000001FFFC510000 > --- Process 7888 unloaded DLL at 000001FFFC510000 > 6358 [main] mandb 7888 child_info_fork::abort: > T:\cygwin64\bin\cyggdbm-4.dll: Loaded to different address: > parent(0x1FFFC510000) != child(0x150000) > --- Process 7888 thread 14024 exited with status 0x800000 > --- Process 7888 thread 10144 exited with status 0x800000 > --- Process 7888 thread 10792 exited with status 0x800000 > --- Process 7888 exited with status 0x800000 > 663649 [main] mandb 6288 child_info::sync: pid 7888, WFMO returned 1, > exit_code 0x800000, res 0 > 663743 [main] mandb 6288 sig_send: sendsig 0xD8, pid 6288, signal -73, > its_me 1 > 663771 [main] mandb 6288 sig_send: wakeup 0x2EC > 663800 [main] mandb 6288 sig_send: Waiting for pack.wakeup 0x2EC > 663840 [sig] mandb 6288 wait_sig: signalling pack.wakeup 0x2EC > 663886 [main] mandb 6288 sig_send: returning 0x0 from sending signal -73 > mandb: fork failed: Resource temporarily unavailable > > > The cyggdbm-4.dll is loaded two times: at 0x150000 and at 0x1FFFC510000, > but for some reason unloaded from 0x1FFFC510000. > This looks like a bug in cygwin. > Incorrect cygwin dll unloaded: 837063 [main] mandb 5504 child_info::sync: n 2, waiting for subproc_ready(0x10C) and child process(0x1E4) --- Process 736 created --- Process 736 loaded C:\Windows\System32\ntdll.dll at 00007FFE2FF70000 --- Process 736 loaded C:\Windows\System32\kernel32.dll at 00007FFE2D600000 --- Process 736 loaded C:\Windows\System32\KernelBase.dll at 00007FFE2C730000 --- Process 736 thread 8588 created --- Process 736 thread 14860 created --- Process 736 loaded T:\cygwin64\bin\cyggdbm-4.dll at 000001FFFC510000 --- Process 736 thread 10128 created --- Process 736 loaded T:\cygwin64\bin\cygmandb-2-7-5.dll at 000001FFFB8F0000 --- Process 736 loaded T:\cygwin64\bin\cygiconv-2.dll at 00000003FBBF0000 --- Process 736 loaded T:\cygwin64\bin\cygintl-8.dll at 00000003FBB90000 --- Process 736 loaded T:\cygwin64\bin\cygpipeline-1.dll at 000001FFFB470000 --- Process 736 loaded T:\cygwin64\bin\cygman-2-7-5.dll at 000001FFFB900000 --- Process 736 loaded T:\cygwin64\bin\cygwin1.dll at 0000000180040000 --- Process 736 loaded T:\cygwin64\bin\cygwin1.dll at 0000000000E50000 --- Process 736 loaded T:\cygwin64\bin\cygwin1.dll at 00000000019D0000 --- Process 736 loaded T:\cygwin64\bin\cygwin1.dll at 0000000001410000 --- Process 736 loaded T:\cygwin64\bin\cygz.dll at 000001FFFACF0000 --- Process 736 unloaded DLL at 00000000019D0000 --- Process 736 unloaded DLL at 0000000001410000 --- Process 736 unloaded DLL at 0000000180040000 2 [main] mandb (736) t:\cygwin64\bin\mandb.exe: *** fatal error - cygheap base mismatch detected - 0x1802FC408/0x110C408. -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-13 21:05 ` Evgeny Grin @ 2016-10-15 10:28 ` Tony Kelman 2016-10-16 0:08 ` Evgeny Grin 0 siblings, 1 reply; 13+ messages in thread From: Tony Kelman @ 2016-10-15 10:28 UTC (permalink / raw) To: Evgeny Grin, cygwin > 2 [main] mandb (736) t:\cygwin64\bin\mandb.exe: *** fatal error - > cygheap base mismatch detected - 0x1802FC408/0x110C408. As far as I can tell, build 14946 fixed whatever the problem was. Crisis averted, for now. -Tony -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Random "child_info_fork::abort:" 2016-10-15 10:28 ` Tony Kelman @ 2016-10-16 0:08 ` Evgeny Grin 0 siblings, 0 replies; 13+ messages in thread From: Evgeny Grin @ 2016-10-16 0:08 UTC (permalink / raw) To: Tony Kelman, cygwin On 15.10.2016 1:58, Tony Kelman wrote: >> 2 [main] mandb (736) t:\cygwin64\bin\mandb.exe: *** fatal error - >> cygheap base mismatch detected - 0x1802FC408/0x110C408. > > As far as I can tell, build 14946 fixed whatever the problem was. > Crisis averted, for now. > > -Tony > > Confirming. Windows build 14946 is fine. Cygwin64, Msys2 (both x32 and x64) now works correctly. As well as Msys2-based tools, like git for windows. May be that was a bug in Windows: FreeLibrary() unload wrong .DLL image with same filename. Suspect that it's not a typical situation for developers of Windows when some app/lib sequentially loads/unloads same .DLL but on different positions. As Windows actually unload .DLLs after some delay - it just unloaded wrong image. That's my guessing. -- Best Wishes, Evgeny Grin -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-10-15 10:28 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-12 5:59 Random "child_info_fork::abort:" Evgeny Grin 2016-10-12 8:36 ` Brian Inglis 2016-10-12 12:00 ` Evgeny Grin 2016-10-13 4:43 ` Evgeny Grin 2016-10-13 12:00 ` Evgeny Grin 2016-10-13 12:31 ` Marco Atzeri 2016-10-13 13:12 ` Eliot Moss 2016-10-13 14:35 ` Brian Inglis 2016-10-13 16:29 ` Evgeny Grin 2016-10-13 17:56 ` Evgeny Grin 2016-10-13 21:05 ` Evgeny Grin 2016-10-15 10:28 ` Tony Kelman 2016-10-16 0:08 ` Evgeny Grin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).