X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=LETRpNDGsKI7Y7rp3f4gkbOL0hPaIoByG1weaifYtWxduR7BEN43b
	Nv/88WpxbvnGS5MOmOAJzGR1+3vJLWC8r58BiTuoB5M3LdTJCjSD12LpHDDJx4GD
	yEZyeZCUL2CV+vj98OHEs18p4R7HMSObfwz8FK4BpKffsq8yyFqcAQ=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=t10OwQEwtVH7DtOEWSdqdGZNXic=; b=U3E/c4msEBgAVptwq04fq/uxqfyh
	mCGAha42Mfisltm+DUoNOyMmkACWwJ45FzWlao9zopJEYdfZuJtDrkPHmk5xDU9e
	EWHKD49MqoXoeDxa5dJURCbi9j+HeGwX6qbZvf0CuTJ4AcUFJrnFjS5urgYKg9NR
	5hi2Z+il2Hl5p4s=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
Date:	Fri, 1 Jul 2016 11:30:33 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Why does ldd not show cyg*.dll in its output?
Message-ID:	<20160701093033.GV981@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<3AD694B4-17D4-4963-88FD-435AD4DD36D5 AT etr-usa DOT com> <4b37d689-285d-7dd4-3e3d-d40b4ee2f81f AT cygwin DOT com> <cb61e083-4229-6662-4815-130c41dfe2a4 AT t-online DOT de> <8AFB6FBD-0E6A-4DE7-BB08-61D12D20ED40 AT etr-usa DOT com> <1b8d57d1-b8f8-6027-ef4a-073a60fbae84 AT gmail DOT com> <a62bb487-1a0c-77a0-ce29-09520dcbdb7b AT gmail DOT com>
MIME-Version:	1.0
In-Reply-To:	<a62bb487-1a0c-77a0-ce29-09520dcbdb7b@gmail.com>
User-Agent:	Mutt/1.6.1 (2016-04-27)

--KSyhVCl2eeZHT0Rn
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 <cygthre=
ad::stub(void*)>}=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"

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

- Raw text -