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 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