This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: semi-solved: fork-related access violations on win7-x64
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Sat, 16 Apr 2011 09:51:04 -0400
- Subject: Re: semi-solved: fork-related access violations on win7-x64
- References: <4DA9310E.9090309@cs.utoronto.ca>
- Reply-to: cygwin-developers at cygwin dot com
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