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

[Christopher Faylor]

On Mon, Feb 28, 2011 at 11:01:46AM +0100, Corinna Vinschen wrote:
>On Feb 27 19:57, Christopher Faylor wrote:
>> On Sun, Feb 27, 2011 at 10:37:03PM +0100, Corinna Vinschen wrote:
>> >On Feb 27 12:05, Christopher Faylor wrote:
>> >> On Sun, Feb 27, 2011 at 10:46:27AM +0100, Corinna Vinschen wrote:
>> >> >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.
>> >
>> >That's weird.  It doesn't work for me.  As soon as winmm is loaded with
>> >the DONT_RESOLVE_DLL_REFERENCES flag on Windows 7, my shell becomes
>> >unusable.  The shell itself runs, but every single try to start another
>> >application (including the stuff in startup scripts) fails with a SEGV,
>> >sometimes with, sometimes without creating a stackdump.
>> >
>> >Maybe that's because I'm running tcsh.  Probably tcsh does something at
>> >every fork which triggers loading the winmm multimedia timer functions,
>> >while bash doesn't.
>> 
>> Ok, this change is making me pretty nervous if it is that picky.  It
>> shows no problems at all when running bash.  And, I tried it on NT4,
>> Windows 7, Windows XP, and Windows 2008.
>
>Yes, it works for me, too, when using bash.  However, that only means
>that bash is not a good testcase for this change.
>
>> Since it is so sensitive, wouldn't it be safer to just add libwinmm.a to
>> DLL_IMPORTS in Makefile.in and forget about trying to stand on our heads
>> to make this work right when loaded dynamically?
>
>I don't think so for two reasons. 
>
>First, the current incarnation of dll_load only tries to use this flag
>if the first call to LoadLibrary really breaks, and only if it really
>breaks with ERROR_INVALID_ADDRESS.  Since that apparently doesn't happen
>on newer OSes(*), the LoadLibraryEx call is only performed to work
>around a problem in a very specifc situation with a single DLL in an
>older versions of Windows, while the code behaves exactly as before in
>all other circumstances.  Given the limited impact, I don't see a
>problem with that. 
>
>Second, last year I proposed to add more DLLs to DLL_IMPORTS, because I
>thought that this might speed up loading Cygwin.  My tests, however,
>showed slowdowns between 2.5 and 25%, depending on the DLL I added to
>DLL_IMPORTS.  I don't think it's a good idea to slowdown all of Cygwin
>on all OSes to workaround a bug in a single DLL on a single OS.
>
>
>Corinna
>
>
>(*) Actually I tried to reproduce the problem on Windows NT4, 2000, XP,
>    2003, 2008, and W7.  Only XP was affected at all.

I tried to reproduce on most of those and saw nothing too.  I just don't
know what situation this will crop up in.  We don't check specifically
for XP so we may be introducing weird hard-to-diagnose behavior.

All strange behavior would be guaranteed gone if we loaded the DLL
statically.  I wonder if we loaded the DLL statically and only removed
on symbol from the autoload if it would help with any slowness in
linking since we'd still be linking all of the symbols dynamically.

cgf