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=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Fri, 1 Jul 2016 11:30:33 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
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> <cb61e083-4229-6662-4815-130c41dfe2a4@t-online.de> <8AFB6FBD-0E6A-4DE7-BB08-61D12D20ED40@etr-usa.com> <1b8d57d1-b8f8-6027-ef4a-073a60fbae84@gmail.com> <a62bb487-1a0c-77a0-ce29-09520dcbdb7b@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: <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--