strange crashes on invocation
Fri Sep 24 16:37:00 GMT 2010
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).
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
More information about the Cygwin-developers