Extend faq.using to discuss fork failures

[Ryan Johnson]

On 19/08/2011 10:35 AM, Corinna Vinschen wrote:
> On Aug 19 09:43, Ryan Johnson wrote:
>> Hi all,
>>
>> I propose to add an entry to cygwin's faq.using which covers fork
>> failures. Frankly, I'm surprised it wasn't there years ago... it's
>> certainly frequently-asked, and the answer is always the same. Right
>> now users have to trawl the archives to figure out what to do (or
>> more likely, just blindly spam the list and get told to rebase
>> and/or trawl the list archives).
> If you convert the text into a patch against faq-using.xml and send
> it to cygwin-patches, I'd take it.
Silly me... I should have realized that even the web site's content 
would be under revision control.

>> Also, what is the status of "the spawn family of calls provided by
>> Cygwin" [1]? There's nothing about it at the API page [2], and a
>> search though the user guide [3] comes up empty as well.
> Have a look into the section called "Process Creation".  Granted, it's
> not much.  These functions are practically foster children only.
I was quoting from the Process Creation section. I can't find anywhere 
else that mentions spawn at all.

>> Searching
>> /usr/include turns up only /usr/include/process.h, which contains
>> only the function declarations and a single comment -- "This file
>> comes with MSDOS and WIN32 systems" -- indicating that Windows, not
>> cygwin, provides the functions (which, incidentally, are deprecated
> No, no, Cygwin provides these functions as well.
Does that mean Cygwin provides an independent implementation of the 
functions which should be used instead of the ones from Windows, or just 
that those functions are among the windows-native calls which cygwin 
makes available out of the box?

>   Apart from that, the
> process.h file is a problem since it duplicates the exec function
> declarations which are given in sys/unistd.h.  I'll remove them.  If you
> want to document them as special Cygwin functions, feel free to add a
> spawn.sgml file to winsup/cygwin which can be included into the section
> about Cygwin-specific functions, like, for instance, path.sgml or
> security.sgml.
Whether that makes sense (and what gets written) would depend on the 
answer to the above, I think.

>> 3. With Vista and later, use peflagsall to set the TS-aware bit on
>> all cygwin dlls (see /usr/share/doc/Cygwin/rebase-3.0.1.README,
>> reboot needed for changes to take effect). This exploits a side
>> effect of address space layout randomization which (ironically)
>> causes dlls to nearly always load at the same address.
> I'm not sure I ever read about that.  On one hand, the TS-aware flag is
> set by gcc 4.x automatically, on the other hand, the TS flag is only
> relevant for actual Terminal Servers.
> Do you mean the dynamicbase flag, maybe, as described by Chuck at one
> point, years ago, on the cygwin-apps list?  Still, I doubt that this
> flag has any positive effect, as far as I understand how it works.
Oops... up to now I always thought tsaware was the flag that affected ASLR.

Reading from this MSDN article [1] clarified things a bit for me. All 
dynamicbase-marked dlls are randomized (including all system dlls). 
Unmarked dlls, and those which load them, will not be randomized. So, 
rebasing dynamicbase dlls would seem to mean little or nothing, and we 
might be able to get away with not rebasing dynamicbase dlls at all (on 
Vista and later, of course). In particular, shipping dynamicbase dlls 
would greatly reduce the need to run rebaseall, because the 
newly-arrived/clobbered dlls would go right into Windows' ASLR bitmap. 
Further, dlls which rebaseall can't catch (like those created and 
dlopened dynamically) might also get a bit of a break. I guess that 
argues for changing gcc/binutils rather than running peflagsall, tho.

Also, we might want to consider *not* marking .exe dynamicbase, because 
"When a thread starts in a process linked with /DYNAMICBASE, Windows 
Vista and later moves the thread's stack to a random location." There's 
no way to turn off heap or mmap randomization, tho, AFAICT.

[1] http://msdn.microsoft.com/en-us/library/bb430720.aspx

Ryan