This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Random "child_info_fork::abort:"

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!)

Not sure that situation is just "test" or "temporary". I'm using
prerelease track so this can go to release.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]