This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: LoadLibrary error 487 (was Re: Please test latest developer snapshot)
On Feb 26 13:14, Christopher Faylor wrote:
> On Sat, Feb 26, 2011 at 07:04:27PM +0100, Corinna Vinschen wrote:
> >Index: autoload.cc
> >===================================================================
> >RCS file: /cvs/src/src/winsup/cygwin/autoload.cc,v
> >retrieving revision 1.183
> >diff -u -p -r1.183 autoload.cc
> >--- autoload.cc 15 Feb 2011 15:56:00 -0000 1.183
> >+++ autoload.cc 26 Feb 2011 17:52:06 -0000
> >@@ -241,6 +241,14 @@ std_dll_init ()
> > error code is neither NOACCESS nor DLL_INIT_FAILED, break out
> > of the loop. */
> > err = GetLastError ();
> >+ if (err == ERROR_INVALID_ADDRESS)
> >+ {
> >+ if ((dll->handle = LoadLibraryExW (dll_path, 0,
> >+ DONT_RESOLVE_DLL_REFERENCES))
> >+ != NULL)
> >+ break;
> >+ err = GetLastError ();
> >+ }
> > if (err != ERROR_NOACCESS && err != ERROR_DLL_INIT_FAILED)
> > break;
> > if (i < RETRY_COUNT)
> >
> >In theory, that should be seriously broken. However, it actually works.
> >This LoadLibraryEx call returns a module handle, and the subsequently
> >fetched function pointer to timeGetTime() is really valid and returns
> >the expected values on XP!
> >
> >I don't understand that. It shouldn't work. But it does.
> >
> >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?
For the records, I also tried to replace LoadLibraryExW with a call
to GetModuleHandle, but that returns error 126, ERROR_MOD_NOT_FOUND.
And I tried this:
if LoadLibraryEx succeeds
FreeLibrary
LoadLibrary
but this results again in error 487, ERROR_INVALID_ADDRESS.
> I think I'd be ok with the change if you made that:
>
> if (err == ERROR_INVALID_ADDRESS && in_forkee)
Good idea. I'll add a big comment to explain why we do this.
> 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.
No go. I tried that and it behaves as expected(*).
> 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?
I think so. Maybe ntdll is first, but I wouldn't bet on it.
> (Of course Microsoft says not to use this flag so I wonder if it will be
> gone or broken in Windows 8)
Where did you read this? I only saw the text which says to be careful
because following calls to LoadLibrary won't call DllMain, just return
the existing module handle.
> cgf
Corinna
(*) STATUS_ACCESS_VIOLATION
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat