SOLVED Cygwin address spaces issue

[qw]

Hi everyone,

Since the latest update of Cygwin to 1.7.10-1, the following error frequently occurs: "child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x7FD50000) is already occupied".

I understand this means that Cygwin cannot load a DLL on a certain base address, which is required because a child created by fork() must have exact the same memory layout as its parent.

I have Googled and read the Cygwin documentation. The only solution I could find was to run rebaseall, an ash script that comes with the Cygwin distribution. This did not solve the problem.

Since many of us are using Cygwin, does anyone else experience this problem? Is there a way to solve it? It is quite annoying, because it happens quite often, especially when running make.

Roel

[Solar]

I have yet to come across that problem, and I run 'make' on Cygwin daily...

Perhaps your Cygwin installation is screwed? I found that, from time to time, a delete-and-reinstall does help keeping an installation fresh. (Not limited to Cygwin, or even Windows.)

[Combuster]

Are you sure you're not mixing versions of DLLs? Like having an older cygwin dll somewhere in %PATH% ?

[qw]

Nope. I completely removed Cygwin and reinstalled it from internet. Then I tried to build nasm from source. I had to run configure five times before it succeeded. So somewhere between the fourth and fifth attempt, something changed.

Perhaps cygiconv-2.dll is not properly unloaded after the first invocation of gcc, and the memory is still occupied during the second. So we just wait until the DLL is removed from memory. I don't know.

Any other suggestions?

[Owen]

I have yet to come across that problem, and I run 'make' on Cygwin daily...

Perhaps your Cygwin installation is screwed? I found that, from time to time, a delete-and-reinstall does help keeping an installation fresh. (Not limited to Cygwin, or even Windows.)

Which version of Windows are you running?

Its an error which is exceedingly rare on Windows XP, and exceedingly easy to trip over on Windows 7 and later.

I remember having it last time I installed Cygwin. What I don't remember is how I fixed it.

...though I think the real solution would be for more developers to use posix_spawn whenever possible.

[Solar]

Its an error which is exceedingly rare on Windows XP, and exceedingly easy to trip over on Windows 7 and later.

That would be it, then. I am in the happy position of using "only" XP on all machines I actually have to use Windows on, and if the current trend continues, I might be able to replace all of them with Linux before someone presses Vista / Win7 / Win8 on me. That would mean WinXP were the last Windows I ever used. Now that would be something to celebrate. (I admit my office workstation might be pushing it a bit, but you never know. )

[Love4Boobies]

Not sure why you're all dissing Windows for a Cygwin bug. On the machine I'm typing from, I have Windows 7 SP1 and am happy with it. In fact, except for a HDD failure, I have never experienced a crash ever since Vista SP1---can't say the same about XP, where it happened quite a lot (current Linux distros would be a not-very-close second, although they have other problems, most notably X11).

[Solar]

We were talking about the observation that this particular Cygwin bug does happen on newer Windows versions more frequently than on older ones.

The one bringing up relative stability of Windows versions in general was you.

[Love4Boobies]

Dang nab it!

[Owen]

Note that these failures come into existence at least partially due to the interplay of Address Space Layout Randomization (i.e. enhanced security) in NT6+ with Cygwin trying to 'hack' fork into existence on a system fundamentally not designed to support it.

Many Anti-Virus/other anti-nasty programs inject DLLs into every started process. These can exacerbate the problem significantly.

Nonetheless, it is possible to get Cygwin working reliably. It just takes some work.

(Notably, I find this to be less work than keeping up with the breakages inflicted by the Linux arts-and-crafts movement on you for having the tenacity to keep your machine "current", generally as a result of the fact that Linux seems to run on "Lets implement this feature" followed by "Lets re-implement this feature because the design sucked" until they iterate through 5 ABI breakages in the course of 2 years and finally get an interface which is maybe somewhere nearly as good as if they'd designed things initially. Unix is still a brilliant toolkit for getting some things done on, which is why I now carry a Mac around with me, because that way simple things like Bluetooth - which has been around since 1994! - just work)

[Love4Boobies]

Btw, I'm an MSYS (the environment distributed by the MinGW folks) user and I don't experience a similar problem. Could look into it as an alternative.

[brain]

Owen, I agree about the annoying random linux abi changes, however its been a while since I encountered one that ground my gears as I tend to put stable or lts etc releases on my systems that only roll out critical fixes instead of prettyness, bleeding edge code and eye candy, which makes lots less work for me in maintaining my laptop... also means Bluetooth, wifi etc just work as opposed to every so often before abi breakage...

[qw]

After reinstalling, I ran rebaseall again and after that, the problem disappeared. I built NASM and even a cross compiler without any trouble. Being unable to reproduce the error, I call this one solved (though it is a little unsatisfying not to know exactly how and why).

Thanks everybody.

Since someone asked: I'm running Windows XP Professional SP2.

[qw]

As a side note, I have always found fork() quite a strange function. Most of the times, all the child does is spawn another program and exit itself. Why create a complete copy of the parent's address space to do that?

[fronty]

In older POSIX standards there's vfork(2), which can be used if child is only meant to call some exec-family function or _exit(2) straight away, but it's probably just better to stick with fork(2).