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

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Sun, Feb 27, 2011 at 10:46:27AM +0100, Corinna Vinschen wrote:
>On Feb 26 18:30, Christopher Faylor wrote:
>> On Sat, Feb 26, 2011 at 10:42:28PM +0100, Corinna Vinschen wrote:
>> >On Feb 26 21:26, Corinna Vinschen wrote:
>> >> On Feb 26 19:45, Corinna Vinschen wrote:
>> >> > On Feb 26 19:43, Corinna Vinschen wrote:
>> >> > > On Feb 26 13:23, Christopher Faylor wrote:
>> >> > > > 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.
>> >> > 
>> >> > Btw., what is the "fn" argument to LoadDLLfuncEx3 good for?  Given that
>> >> > it's always 0 it seems pretty useless right now...
>> >> 
>> >> Erm... I don't know what fn is supposed to do, but right now it's
>> >> value is simply used for the error code.  In LoadDLLprime it's put
>> >> into the upper 8 bytes of the decoration:
>> >> 
>> >>   .long (" #n "+" #notimp ") | (((" #err ") & 0xff) <<16) | (((" #fn ") & 0xff) << 24)
>> >> 
>> >> And in noload it's simply returned together with the err value:
>> >> 
>> >>   [...]
>> >>   andl    $0xffff0000,%eax# upper word
>> >>   [...]
>> >>   pushl   %eax            # Save for later
>> >>   [...]
>> >>   popl    %eax            # Get back argument
>> >>   sarl    $16,%eax        # return value in high order word
>> >>   jmp     *%edx           # Return
>> >> 
>> >> My question is, shouldn't there be an additional
>> >> 
>> >>   andl    $0x000000ff,%eax
>> >> 
>> >> right before the jmp?  This would also allow to use the fn value
>> >> for the purpose discussed above.
>> >
>> >Here's my final patch, assuming I got that right with LoadDLLfuncEx3 and
>> >err and fn.  I'm using the fn parameter to LoadDLLfuncEx3 as an 8 bit
>> >flag value now.  std_dll_init checks if the lowest bit is set, and only
>> >then it calls LoadLibraryExW.  Is that ok?
>> 
>> I chose to do things a little differently.  I store the flag value once
>> per dll and got rid of the fn field entirely.
>
>Thanks, but your code only works on XP, not on Winodws 7.  In fact,
>on Windows 7 Cygwin is now entirly broken since every single fork
>segfaults.

It works for me.  I had tested it on Windows 7.  My simple test case was
just using ssh which always seemed to break when I got the code wrong.
It works fine on Windows 7.  The crash reported on the mailing list also
worked with my changes on Windows 7 and Windows XP.

I just tried it on NT4 too and, bash, at least works.  I don't have
enough stuff loaded to test ssh but I'll do that.

>dll_load can't just call LoadLibraryExW(DONT_RESOLVE_DLL_REFERENCES) on
>winmm just because it's in a forkee.  It has to check if a prior call to
>LoadLibrary (or LoadLibraryExW(0) failed with ERROR_INVALID_ADDRESS since
>only an OS on which that happens is affected by the problem.  Otherwise,
>as I wrote in http://cygwin.com/ml/cygwin-developers/2011-02/msg00012.html,
>it's plain wrong to load a DLL with the DONT_RESOLVE_DLL_REFERENCES flag
>set, if you need a working copy of that DLL.

If you were actually implementing what I meant then what you wrote in
http://cygwin.com/ml/cygwin-developers/2011-02/msg00012.html was that it
was "expected" that using DONT_RESOLVE_DLL_REFERENCES would result in a
SEGV if applied to every dll in a forkee.  My code doesn't (or at least
was not supposed to) do that.  It's only supposed to be invoked for
winmm in a forkee.  In case it isn't clear, I was trying to avoid YA
slowdown to fork by only calling LoadLibrary once.

I'd actually tried the "do it for all dlls" experiment myself after
suggesting it and saw that it didn't work but that it did work with just
pinpointing winmm.

Oh and I forgot to respond to this:

On Sat, Feb 26, 2011 at 07:40:45PM +0100, Corinna Vinschen wrote:
>On Feb 26 13:14, Christopher Faylor wrote:
>>(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.

http://msdn.microsoft.com/en-us/library/ms684179%28v=vs.85%29.aspx

  "Note Do not use this value; it is provided only for backwards
  compatibility.  If you are planning to access only data or resources in
  the DLL, use LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE or
  LOAD_LIBRARY_AS_IMAGE_RESOURCE or both.  Otherwise, load the library as
  a DLL or executable module using the LoadLibrary function."