strange crashes on invocation

[Heath Kehoe]

On 9/24/2010 5:48 AM, Corinna Vinschen wrote:
>
> We typically have problems with two DLLs, which are both used very
> often, ws2_32.dll and user32.dll.  Both are not linked in to the cygwin
> dll, but only loaded dynamically via autoload.
>
> So I'm wondering if dynamic loading is the culprit here.
>
> The core system DLLs are usually loaded at the exact same spot over the
> entire uptime of a system, *if* the application is load-time linked
> against the DLL.  This is still true for the later Windows versions
> supporting ASLR.  The randomization only takes place at reboot.  This
> speeds up loading of applications since it allows easier sharing of
> already loaded DLLs.
>
> Of course, this doesn't apply anymore if a DLL is only linked at
> runtime.  In that case the DLL gets loaded where it fits in, and if it
> doesn't fit in at its usual spot, it will be loaded elsewhere.  We don't
> even know if Windows will actually use the same algorithm to load one of
> the system DLLs when it's runtime loaded.  So we're back to the usual
> fork problem.
>
> What I'd like to propose is to minimize autoloading to the entry points
> which are not available on all OSes.  Other than that, we should link
> cygwin against all used system DLLs so it can profit from the fixed
> DLL addresses and the potential speed advantage the DLL sharing grants.
>
> I'm already running a local Cygwin with minimized autoload.cc.
> Unfortunately I can't reproduce the problem, but it might be worth to
> let the guys try who encounter the error.
>
> Btw., I think we should also drop support for NT up to SP3.  Nobody
> with a sane mind would run NT4 without SP6a, but SP4 is the first
> version which made NT4 usable anyway.
>

I'm willing to test your minimized autoload.cc (or whatever else) in my 
environment. Our build system is a bit of a stress test (it'll max out 
all the CPU cores and disk IO).

-h


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________