From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117074 invoked by alias); 13 Jan 2016 10:45:27 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 117000 invoked by uid 89); 13 Jan 2016 10:45:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-93.0 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,KHOP_DYNAMIC,RCVD_IN_BRBL_LASTEXT,RCVD_IN_PBL,RDNS_DYNAMIC,USER_IN_WHITELIST autolearn=no version=3.3.2 spammy=grows, H*f:sk:76XBA0w, H*f:CAFo71_6gZ8D, H*i:CAFo71_6gZ8D X-HELO: calimero.vinschen.de Received: from ipbcc05c50.dynamic.kabel-deutschland.de (HELO calimero.vinschen.de) (188.192.92.80) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Jan 2016 10:45:20 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 60B7CA80595; Wed, 13 Jan 2016 11:45:18 +0100 (CET) Date: Wed, 13 Jan 2016 11:02:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Problem with Cygwin 2.4.0-0.18 release Message-ID: <20160113104518.GA16198@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20160112092831.GA15034@calimero.vinschen.de> <20160112095023.GC15034@calimero.vinschen.de> <20160112150538.GE15034@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-01/txt/msg00161.txt.bz2 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3435 On Jan 13 09:59, Ismail Donmez wrote: > Hi, >=20 > On Tue, Jan 12, 2016 at 5:05 PM, Corinna Vinschen > 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. >=20 > 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 --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWliq+AAoJEPU2Bp2uRE+gGlkQAIRhIInawkLF99hWe1jeR0Ic NGv/14JW/mC5aFIN4YYazro9YR5wd9aTBkp8jkxpLC2/PjyccRhVQUpWmtUJ7/at NxBTOIVb3VL6fS7mZgDNQlJRprnMEFNmbyiCVtNjNWF1wRLyMsQsAPdSHRP9emvd XfHDKEhV05GgOvAZB8eTgaUHIUYR5rgkhBtbp3BJpDoeBqUeHJhXzfasFBEmuTvE TGMa1ElYhcdnKHBv1jllYLFlvzlCwiBoiaHR0YOpIH6+RHEDKgPVU24h8m1qHsOb 3V4GdrVPqNejGvjtv5Mj0BEXJkEOD3cwMxfAcwI+1LdKJw3MIU4hkqTgsRuKAfcD YlYAv/HaaTLD56l12lwHtbEMc4SWC3NZOjUSOl0cB4ifmgOyV4xpmCXFm6e7N9fE eBzsUVU+lfLPoC2LCGkHYOaYNeRFKg/k2gxrZbHRiYdej7MdHwwFg39VoLb13+Sr 8iQ8irkzghfeYIPBWkn9vsNrQt+/j5Hx8NQa599Oa0L5C2tCUcGK7DQMXeySQZ4d PZUi1SKbJgcBC87AVnQSsaoVoXCrVFsO4K5WwDqgH4Ugmf12PYT8KVndMpORkrCs xH8zqNEze7yEh4VxIpZdN1UfLzT7lDrgnB8ZwK89PGkJggm2yOfWlkRcUT0rQub/ 9WTaP3rvEJdSWcIaIfA8 =EHXI -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X--