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

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

Guys


I'm seriously puzzled.  Any input would be much appreciated.

On Feb 26 11:35, Corinna Vinschen wrote:
> On Feb 25 16:09, David Rothenberger wrote:
> > I was able to reproduce this using a clone of the git repository itself:
> > 
> > % uname -a
> > CYGWIN_NT-5.1 tela 1.7.8s(0.236/5/3) 20110221 20:36:00 i686 Cygwin
> > % git clone git://github.com/git/git.git
> > Cloning into git...
> > remote: Counting objects: 134689, done.
> > remote: Compressing objects: 100% (39672/39672), done.
> > remote: Total 134689 (delta 100250), reused 126970 (delta 93150)
> > Receiving objects: 100% (134689/134689), 28.44 MiB | 621 KiB/s, done.
> > Resolving deltas: 100% (100250/100250), done.
> > % cd git/
> > % git log
> >       0 [main] git 3088 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
> 
> Thanks for the report.  I can reproduce this under Windows XP but
> not under Windows 7.  Stay tuned.

What happens on XP is that at one point when git calls select(), the
timeout value in the select call triggers a call to hires_ms.nsecs().

The crash occurs in this line:

  LONGLONG res = initime_ns + (((LONGLONG) timeGetTime ()) * 10000LL);

timeGetTime is loaded via the autoload mechanism from winmm.dll.
This LoadLibrary call fails with error 487, ERROR_INVALID_ADDRESS.

David mentioned that it works with then 20100924 snapshot and failed
to work with the 20100926 snapshot.  The important difference between
these two snapshots is the removal of NT4 pre-SP4 support.  This in
turn allowed to simplify a couple of LoadDLLfunc expressions.

I tracked the above problem down to this simple change:

  -LoadDLLfuncEx (timeGetTime, 0, winmm, 1)
  +LoadDLLfunc (timeGetTime, 0, winmm)

The difference is that the old version did NOT fail, even if LoadlLibrary
failed.  It just returned 1 in that case.  The new version now potentially
fails with the Win32 error returned by LoadLibrary.

However, this occurs on XP SP3, not on some old NT4.  The timeGetTime
function is available, but loading it failed with this puzzeling 
ERROR_INVALID_ADDRESS.

The worst thing here is that this fails even with the 20100924 snapshot,
if I only change the aforementioned line, and it fails in the same spot.
This means that this call to timeGetTime() has failed to work for a long
time.  We just never noticed it, because the autoload statement ignored
this problem and the call to timeGetTime() simply return 0.

It also has nothing to do with the std_dll_init() function.  It does not
matter if I try to load by path or by name.  It does not matter if the
FP environment is saved and restored or not.  There's just no good
reason that this LoadlLibrary call fails with ERROR_INVALID_ADDRESS.

The only workaround which works for me is to use the GetTickCount()
function instead of the timeGetTime() function in hires_ms::nsecs():

Index: times.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/times.cc,v
retrieving revision 1.103
diff -u -p -r1.103 times.cc
--- times.cc	9 Aug 2010 16:47:47 -0000	1.103
+++ times.cc	26 Feb 2011 15:21:38 -0000
@@ -687,12 +687,12 @@ hires_ms::nsecs ()
     prime ();
 
   LONGLONG t = systime_ns ();
-  LONGLONG res = initime_ns + (((LONGLONG) timeGetTime ()) * 10000LL);
+  LONGLONG res = initime_ns + (((LONGLONG) GetTickCount ()) * 10000LL);
   if (res < (t - 40 * 10000LL))
     {
       inited = false;
       prime ();
-      res = initime_ns + (((LONGLONG) timeGetTime ()) * 10000LL);
+      res = initime_ns + (((LONGLONG) GetTickCount ()) * 10000LL);
     }
   return res;
 }

Does anybody have an idea what could cause this problem?  I already
googled for this but all I can come up with is questions with no reply
or questions which refer to loading a DLL as data or resource.  And
the replies aren't very helpful either.


Corinna

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