semi-solved: fork-related access violations on win7-x64

[Christopher Faylor]

On Sat, Apr 16, 2011 at 02:02:54AM -0400, Ryan Johnson wrote:
>Hi all,
>
>I've isolated one source of access violations on my win7-x64 machine, 
>and it's nasty.
>
>The offending series of events is:
>1. Two linked-in dlls share the same base address
>2. The process forks
>3. Windows assigns the child's dll a different base addresses than it 
>chose for the parent
>4. This code from dll::init () (dll_init.cc) runs in the child, with p 
>addresses from the parent:
>> 1.75         (07-May-10):   /* This should be a no-op.  Why didn't we 
>> just import this variable? */
>> 1.78         (27-Mar-11):   if (!p.envptr)
>> 1.78         (27-Mar-11):     p.envptr = &__cygwin_environ;
>> 1.79         (06-Apr-11):   else if (*(p.envptr) != __cygwin_environ)
>> 1.78         (27-Mar-11):     *(p.envptr) = __cygwin_environ;
>
>It was only recently that "somebody" noticed that the envptr could be 
>wrong and added code to "fix" it, but that leaves all the other members 
>of p just as wrong as before. If we're lucky, p points to unmapped 
>memory, causing one access violation; otherwise, we jump off into la-la 
>land and do who-knows-what with bad addresses.

The "fix" is part of an ungoing investigation into a problem which has
been reported in the cygwin list.  It doesn't, in fact, even deal with
the reported problem.

http://cygwin.com/ml/cygwin/2011-04/msg00001.html

Corinna and I have talked about making it a fatal error, suggesting
rebase, but, as it turns out rebase doesn't fix this particular problem
either.

cgf