This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]