This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]