On 2:59 PM, Jon TURNEY wrote:
On 15/03/2011 13:53, Ryan Johnson wrote:
All of this assumes Windows is consistent in choosing locations when conflicts
It's assumed that CreateProcess() produces the same layout, yes.
This assumption is due to what?
- Documented Windows feature?
- An observation which holds in spite of tests/abuse which try to
exercise corner cases?
- A wish which comes true often enough to get by in most cases?
I suggest you read how-startup-shutdown-works.txt and then observe that
dll_list:alloc() is called by dll_dllcrt0_1()
Thanks for the pointer. Unfortunately, it doesn't tell much about
fork(), nor does it make clear when memory for dependent dlls is
assigned. The loader calls dependent dllmains right before entering the
. owner's dllmain, but that doesn't say when the address space is
reserved. There's the complexity of deferred vs. immediate dllmain calls
as well.
I look forward to reading your patches :-)
I think it's still rather premature to be cooking up a patch,
unfortunately -- I'm not convinced I know yet where the real problem
lies. Without some data to back up my speculation (which seems hard to
come by), any patch I might write would have a high probability of
joining other accumulated band-aids such as reserve_upto().
Open questions (for my ignorant self, at least) include:
- Does Windows always load a given dll at the same address when its base
address is already occupied?
- Does fork() always load DLLs in the same order that the parent loaded
them? This would probably be helpful to know even in cases where no
error arises, because it's a necessary precursor to fork failures, and
the code seems to assume it's true.
- Is it ever possible for fork() to unload BLODA dlls?
- Do injected dlls arrive before or after statically-linked dlls? Or can
it be either one?
- At fork time, does cygwin mogrify some generic child process to look
like the parent, or is the child another "normal" run of the parent's
executable image followed by plastic surgery to make heap, stack, etc.
match? I had been assuming the former, but should probably ask.
If if statically-linked dlls ever need to be loaded manually by fork(),
and injected dlls arrive after statically-linked ones, then that might
explain BLODA right there: If static.dll and bloda.dll both have the
same base address, and dll injection occurs after statically-linked
dlls, and fork() ever needs to load static.dll manually, then that would
be (at least one) way bloda can arise.
Is there any way to have cygwin report dlls, base addresses, and
windows-assigned addresses for dlls when a fork fails?
Thoughts?
Ryan
--
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
