From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72204 invoked by alias); 1 Jul 2016 09:30:49 -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 72148 invoked by uid 89); 1 Jul 2016 09:30:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-95.1 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_BRBL_LASTEXT,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=H*f:sk:a62bb48, Hx-languages-length:3711, H*MI:sk:a62bb48, H*i:sk:a62bb48 X-HELO: calimero.vinschen.de Received: from ipbcc0190b.dynamic.kabel-deutschland.de (HELO calimero.vinschen.de) (188.192.25.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Jul 2016 09:30:36 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id A46B3A80926; Fri, 1 Jul 2016 11:30:33 +0200 (CEST) Date: Fri, 01 Jul 2016 09:30:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Why does ldd not show cyg*.dll in its output? Message-ID: <20160701093033.GV981@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <3AD694B4-17D4-4963-88FD-435AD4DD36D5@etr-usa.com> <4b37d689-285d-7dd4-3e3d-d40b4ee2f81f@cygwin.com> <8AFB6FBD-0E6A-4DE7-BB08-61D12D20ED40@etr-usa.com> <1b8d57d1-b8f8-6027-ef4a-073a60fbae84@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KSyhVCl2eeZHT0Rn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-SW-Source: 2016-07/txt/msg00007.txt.bz2 --KSyhVCl2eeZHT0Rn Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4280 Hi David, On Jun 30 23:27, David Macek wrote: > On 29. 6. 2016 23:45, David Macek wrote: > > I can try watching them side by side in debuggers tomorrow, maybe I'll = find something. >=20 > Yep, found something. TL;DR the issue is that Windows spins a thread > in the process before our DLLs are loaded. Detailed analysis below. > [...] > 8. EXIT_PROCESS_DEBUG_EVENT >=20 > Event #6 is the culprit here. NT apparently starts a thread in our > process which confuses ldd into believing that the process has > finished loading DLL from its import table and kills it, as explained > above. The thread appears non-deterministically, too, sometimes I see > event #5 (and the associated DLL in ldd's output), sometimes not. The > thread's entry point is always the same and ProcExp reports the same > location (I checked in case of some symbol mash-up, as it often > happens when debugging across the Cygwin-Windows boundary). When I > broke ldd at `case CREATE_THREAD_DEBUG_EVENT`, the new thread's stack > trace (from ProcExp) looked like this: > [...] > After some experimentation, I came up with a patch that tries to > determine whether to ignore a thread based on the thread's entry point > lying inside or outside of the memory occupied by ntdll.dll: Nice detective work! As for the below patch, I think the condition should be turned around to test if the thread entry point is inside the Cygwin DLL. This event: 10. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread =3D {hThread =3D 0x88, lp= ThreadLocalBase =3D 0x7ff5ffffb000, lpStartAddress =3D 0x180044cf0 }=20 denotes that we are ready. So instead of contining if the thread entry point is inside ntdll, continue as long as the entry point is not in the Cygwin DLL. That would also have the advantage to be independent of future changes in Windows as well as injection from virus checkers etc. What do you think? > --- ldd.cc.orig 2016-04-28 21:54:57.556500700 +0200 > +++ ldd.cc 2016-06-30 23:24:20.394384800 +0200 > @@ -327,6 +327,10 @@ > { > bool exitnow =3D false; > DWORD cont =3D DBG_CONTINUE; > + MODULEINFO mi; > + HMODULE ntdll =3D LoadLibrary("ntdll.dll"); > + HMODULE ntdllend =3D NULL; > + void *entryPoint; > if (!WaitForDebugEvent (&ev, INFINITE)) > break; > switch (ev.dwDebugEventCode) > @@ -357,6 +361,31 @@ > } > break; > case CREATE_THREAD_DEBUG_EVENT: > + if (ntdll !=3D NULL) > + { > + if (ntdllend =3D=3D NULL) > + { > + /* Using our ntdll.dll HMODULE with a foreign process > + should be fine because ntdll.dll is mapped to the s= ame > + address in every concurrently executing process and > + HMODULEs are just pointers to the image in the proc= ess > + memory. Using GetModuleHandle(NULL) didn't work for= the > + author of this code (-> ERROR_INVALID_HANDLE). */ > + if (GetModuleInformation(hProcess, ntdll, &mi, sizeof(= mi))) > + ntdllend =3D ntdll + (ptrdiff_t)mi.SizeOfImage; > + else > + ntdll =3D NULL; > + } > + if (ntdllend !=3D NULL) > + { > + entryPoint =3D (void*)ev.u.CreateThread.lpStartAddress; > + /* If the thread's entry point is in ntdll.dll, let's > + assume that this isn't the program's main thread and > + ignore it. */ > + if (ntdll <=3D entryPoint && entryPoint < ntdllend) > + break; > + } This check can be simplified. Rather than explicitly checking for start and end address of ntdll.dll (or cygwin1.dll), one could just find the file for a given address: wchar_t fnamebuf[MAX_PATH]; if (GetMappedFileNameW (hProcess, (PVOID) ev.u.CreateThread.lpStartAddress, fnamebuf, sizeof fnamebuf) && wcsstr (fname, L"cygwin1.dll")) printf ("bingo\n"); Thanks, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --KSyhVCl2eeZHT0Rn Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXdjg5AAoJEPU2Bp2uRE+gawoQAJV1VOSA5tcR6sMacPJ+hGdv orTWm8CShmTHxcDsbpNchc+TSnFnIYd480yXnluHQpQlP+4DRdkvKPArCRMXGMfa 5F7mL1JS8Z4fTtmwI7h91PYl7mzA9Ssj6wb0j3tJ475968cQgx77RpmxcdxndE9j vVEJeYR0BP+SKX5fOXTuJiImz8HEygk0zPeJURg/TdY3rbGexv1IRIHwMPiGeRF0 fx6n3TCnzkOj44RUgPqB2nFDTb6v7g/Voo8OUOgia9sfNJgqQs93EolvUkqPAgpj jlrUxYmrb/kTukQNLDzqbDvQ8VGbrPdlsAduSKL+BnUzoIizBhTBBbXdboCMnUZD p4YiG2fsVuZzTpNNcahQsdkC0OgtnH5v/LkVeICHcfNMD1IYTIse24QT4x3IjKEX Jn0tgBbgeGCuZvacYmD+K/weV3Ztl6YyG1Y+6jIAcQjCIeTarx/jxE+WtASAOBGg 5R9zk8N50/2ew+ZxBWBsTYjt+BczsPgJTkmLiTf14anbLxiKemvO6cfzBq1j/w+o tgs3IIvA5dRsrvZaoP7o5+8uK54N3YHrD+p6/QZFBvRtsCNSO1xPL6WbUAZ55im0 WNJ/PaLzxue5TmTctr5/WvbeCUHQ0srhfuhexOTQjd2T5hsgLZe6juXRf4MznPi3 vdu3sElDYdFBT2jz8lHK =YXLO -----END PGP SIGNATURE----- --KSyhVCl2eeZHT0Rn--