Debugging help for fork failure: resource temporarily unavailable

[Ryan Johnson]

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