LoadLibrary error 487 (was Re: Please test latest developer snapshot)

Corinna Vinschen corinna-cygwin@cygwin.com
Sat Feb 26 18:43:00 GMT 2011


On Feb 26 13:23, Christopher Faylor wrote:
> On Sat, Feb 26, 2011 at 01:14:33PM -0500, Christopher Faylor wrote:
> >On Sat, Feb 26, 2011 at 07:04:27PM +0100, Corinna Vinschen wrote:
> >>On Feb 26 16:32, Corinna Vinschen wrote:
> >>Chris, what do you think?  Is that something we should try?  Maybe we
> >>should try this only if we set a flag in some not yet existing
> >>LoadDLLfuncEx4?
> >
> >I think I'd be ok with the change if you made that:
> >
> >if (err == ERROR_INVALID_ADDRESS && in_forkee)
> >
> >It's still not foolproof but at least we wouldn't be affecting non-forked
> >processes and, in theory, the data segments of loaded dlls would be properly
> >filled out in a fork().
> >
> >In fact, hmm.  I wonder if you could just change std_dll_init so that it
> >always used DONT_RESOLVE_DLL_REFERENCES when in_forkee.  That might speed
> >fork up a little.
> >
> >This also assumes that Cygwin got in first to load the dll and that it's
> >being loaded during fork startup but I think that is a given, right?
> >
> >(Of course Microsoft says not to use this flag so I wonder if it will be
> >gone or broken in Windows 8)
> 
> The other thing we could do is add a flag to thd dll_info struct which says
> "Use DONT_RESOLVE_DLL_REFERENCES" either in the forkee or always depending
> on what works for winm.dll.

That's what I meant above.  It would require a new LoadDLLfuncEx4,
wouldn't it?  OTOH, LoadDLLfuncEx3 is only referred to via the
definition of LoadDLLfuncEx2, so it should be simple to redefine.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat



More information about the Cygwin-developers mailing list