Fri Apr 15 12:47:00 GMT 2011
This message is in reference to the ongoing discussion about fork
failures, a which I'd like to work on and hopefully fix.
There seem to be (at least) three separate problems related to fork():
1. Two or more dlls can have the same base address, leading to failures
to lay out a posix-compliant address space in the child. This one I'm
particularly interested in fixing, and it looks like (at least for a lot
of cases) changing reserve_upto() and/or being more careful about dll
load order could go a long way.
2. BLODA can do Bad Things to cygwin apps. I get the feeling that this
is becoming a catch-all in some ways -- that most bloda really just
trigger some underlying bug related to (1) rather than being truly Evil.
This is a real problem now that even official Windows components
(windows defender) are making their way onto the list. One thing I'm not
clear about at all is whether BLODA often do anything worse than trigger
(1) above. The FAQ isn't very clear about what "less-than transparant"
means. It's also not clear to me (windows development newbie) whether
injected dlls could ever be unloaded (and possibly later reloaded) when
they cause problems.
3. win7-x64 machines seem to trigger access violations at regular
intervals. I'm not completely sure whether this is a new side effect of
(1), or an independent problem. I suspect the former, since my own
experiments suggest that the access violations occur when a forked child
attempts dll (re)initialization. I'm still diagnosing this one...
My main challenges at this point are
- not knowing an awful lot about how dll loading works (in particular,
automatic loading of dependent libraries and how cygwin and dll
entry/exit points work)
- having no idea how ASLR impacts things. It seems like it should make
the problem go away completely (bloda and all), mooting this whole
discussion, yet here we are
- Reproducing (1) above reliably enough to debug it
- Knowing whether (1) is the only major source of fork failures
Any pointers to either one would be very helpful -- useful online
resources are great (I do know how to read, but my google-foo is not
always strong enough).
More information about the Cygwin-developers