strange crashes on invocation

[Christopher Faylor]

On Fri, Sep 24, 2010 at 12:48:50PM +0200, Corinna Vinschen wrote:
>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
>> > >autoload.cc to see if that makes any difference.
>> > 
>> > I'm currently testing the latest CVS, but with these changes rolled back:
>> > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/autoload.cc.diff?r1=1.170&r2=1.171&cvsroot=src&f=h
>> > 
>> > 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 don't see how fork enters into this since Cygwin doesn't have any
visibility into the data in a system dll.  It shouldn't matter where one
of these guys is loaded.  But, coincidentally enough, I was thinking the
same thing about dropping the dynamic linking.  It is less important now
that we no longer support Windows 9x.

The other motivation for the autoload stuff was supposed to be reducing
the runtime link cost of resolving symbols that would never be used.  It
would be interesting to see if there is any noticeable performance change.
I could see it either getting faster or slower.

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

Agree.

cgf