strange crashes on invocation

Corinna Vinschen
Fri Sep 24 10:49:00 GMT 2010

On Sep 24 11:17, Corinna Vinschen wrote:
> On Sep 23 18:22, Heath Kehoe wrote:
> > On 9/23/2010 3:07 PM, Heath Kehoe wrote:
> > >On 9/23/2010 12:13 PM, Heath Kehoe wrote:
> > >>    I have a build system that uses rake under cygwin, and every so often
> > >>a build tool will crash on invocation:
> > >>
> > >>         1 [main] bclanc 1576! C:\budcat\tools\bin\bclanc.exe: *** fatal
> > >>error - could not load w, Win32 error 998
> > >>Stack trace:
> > >>Frame     Function  Args
> > >>00289F44  6102740B  (00289F44, 00000000, 00000000, 00000000)
> > >>0028A234  6102740B  (61179C20, 00008000, 00000000, 6117B997)
> > >>0028B264  61004B2B  (6117B084, 61163DD0, 00000000, 00000000)
> > >>0028B4C4  6100137A  (61053A9A, 00000168, 00000002, 00000002)
> > >[snip]
> > >>My OS is Win7 x64. Cygwin is built from CVS as of 2010-09-21 12:11
> > >>(though I'm pretty sure I've seen this on 1.7.7 as well)
> > >I've confirmed that this crash is happening on 1.7.7; it does not appear
> > >to happen on 1.7.6.
> > >
> > >Could it be related to the DLL loading change relating to the security
> > >advisory? I'll probably try to revert the revision 1.171 changes to
> > > to see if that makes any difference.
> > 
> > I'm currently testing the latest CVS, but with these changes rolled back:
> >
> > 
> > Thus far, I have not yet seen the crash. I'll hammer on it more to
> > make sure.
> Can you revert to the latest from CVS and try again with this patch applied:
> [...]
> If the error occurs again, what is the path printed in the error
> message?  Is it sane?  Does the directory correspond to your local
> X:\Windows\System32 directory?

Apart from the change to use the pathname instead of just the DLL name,
nothing has changed here, as we all know.  If it works once, there's no
reason that it shouldn't work throughout.  There must be another reason.

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


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

More information about the Cygwin-developers mailing list