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

[Ryan Johnson]

On 16/04/2011 9:51 AM, Christopher Faylor wrote:
> 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.
Thanks for the clarification -- I never would have guessed that the 
above changes were related to a bug reported about octave; the only hint 
from the discussion is a mention in passing that something went wrong in 
dll_init().

It's kind of scary that two different bugs manifest in those four lines 
of code, though.

Ryan