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: Re: Debugging help for fork failure: resource temporarily unavailable


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


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