Problem with Cygwin 2.4.0-0.18 release

[Corinna Vinschen]

On Jan 13 09:59, Ismail Donmez wrote:
> Hi,
> 
> On Tue, Jan 12, 2016 at 5:05 PM, Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> > I tried to workaround this problem by "upgrading" the DLL load
> > mechanism to use the facilities available since Vista.  In theory
> > this should work fine for you.  I uploaded a new developer snapshot
> > to https://cygwin.com/snapshots/  Please give it a try.
> 
> Sadly still getting the same error.

That doesn't make sense.  The new code has a fallback which is identical
to the code in -0.17.  No offence, but are you *sure* you're using the
snapshot DLL?  Uname on 64 bit should print:

 $ uname -srvm
 $ CYGWIN_NT-6.1 2.4.0(0.293/5/3) 2016-01-12 14:54 x86_64

Can you re-check, please?

[...testing myself...]

Ok, so I just set up sshd on a W7 64 bit machine and I can actually
reproduce the problem with -0.18.

However, it starts to work fine for me with the snapshot!

So I added debug output to the Cygwin DLL and there's something strange
going on on W7 64.  When loading ws2_32.dll in this single instance of
logging in to sshd, the LoadLibrary call to ws2_32.dll fails in one of
the child processes with a stack overflow.  The *next* call to
LoadLibrary works fine, though.  My debug output inspected the stack.

Quick introduction for those not overly familiar with this stuff:

- AllocationBase is the memory address the stack has been reserved at.

- StackLimit is the lowest address of the committed region on the stack.
  StackLimit is always > AllocationBase and < StackBase.

- FramePointer is the value of the $ebp register which denotes the current
  stack usage in this function.  FramePointer is always > StackLimit and
  < StackBase.

- StackBase is the uppermost address of the stack, the address from where
  the stack grows downward.

Given this, low values of StackLimit mean a high stack pressure, high
values a low stack pressure.

Here are the stack values on Windows 10 before and after the LoadLibrary
call to ws2_32.dll which works on W10 and W8.1 but fails on W7:

          AllocationBase        FramePointer
                     StackLimit            StackBase
Windows 10:
  before: 0xFFE00000 0xFFFFAE60 0xFFFFBE80 0x100000000
  after : 0xFFE00000 0xFFFF9000 0xFFFFBE80 0x100000000

Windows 8.1:
  before: 0xFFE00000 0xFFFFAE60 0xFFFFBE80 0x100000000
  after : 0xFFE00000 0xFFFFAE60 0xFFFFBE80 0x100000000

Windows 7:
0xFFE00000 0xFFFFAE60 0xFFFFBE80 0x100000000
0xFFE00000 0xFFE01000 0xFFFFBE80 0x100000000
           ^^^^^^^^^^

So, before the call to LoadLibrary, the stack is completely correct, as
on W10 and W8.1.  However, after the LoadLibrary call, the StackLimit
has changed to the maximum possible value.  What does that mean?  For
some reason LoadLibrary(ws2_32.dll) took up all space available on the
stack and then failed because there was no more stack.  Interesting
enough, the *next* call to LoadLibrary then worked as expected.

Why this happens?  I have no idea.  Probably a bug in W7.

So, Ismail, please test again if you're really using the snapshot DLL.
The fact that I can reproduce the problem *and* fix it by running the
snapshot, *and* reproducibly create the error on W7, but not on W8.1
or W10 indicates to me that this sould be fixed for you as well.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20160113/fb917227/attachment.sig>