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=X2w8fK3qVIhnIRn7uW1oKnVFCVmFMfy8W+PjmlC2ctC/GhOP51KOe
	tKDSY/WxktzmdkCmww2K9Cz/CftVrj5luMVXpdiMedFhkaXXW2y4TzR8yLtmdOYf
	nE7i2nnK9G1qaqNztEdWrC02Yk7y7XeYbqPdVZyYaSE3s0AJB9nvTk=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Mon, 20 Oct 2014 18:43:24 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Threads
Message-ID: <20141020164324.GA32374@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <54450835 DOT 3050602 AT cornell DOT edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8"
Content-Disposition: inline
In-Reply-To: <54450835.3050602@cornell.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Oct 20 09:03, Ken Brown wrote:
> When trying to debug emacs in gdb, I see several threads, but it's not
> always clear who created those threads and what they're doing.  As an
> example, I attached gdb to an emacs-X11 process (running under X) shortly
> after starting it, and I obtained the backtrace appended at the end of th=
is
> message.
>=20
> I assume Thread 12 was created by gdb.

Yes, that's the debugging thread created by the OS when a debugger
connects.

Thread 11 and 10 seem to be dead threads which have been added to the
thread pool?!?

Thread 9 is a worker thread for select on a pipe.

Thread 8 and 7 are unrecognizable, I'd bet on a select call in at
least one of them.

> Thread 6 appears to be a timer thread=20

Right, thread 6 is a worker thread for a timer_settime call (also=20
called from setitimer, alarm, ualarm).

Thread 5 is another select on a pipe, thread 4 and 3 again not
recognizable.

> and Thread 2 appears to be a signal thread;

Right.

> I assume both of these
> were created by the Cygwin DLL.  And Thread 1 is the main thread.

Right.  Thread 2, 5, 6, 9 are Cygwin-created threads.

Threads 3, 4, 7 and 8 appear to be application-created threads.  At
least one of them is waiting in a select call, waiting for two pipe
handles, or two of them waiting for one each.  Select itself starts
threads a lot.

Threads 10 and 11 seemed to be ignorable, but I never saw threads
waiting in WaitForWorkViaWorkerFactory myself.  Cygwin does not
utilize the OS thread pools by itself, rather it implements its
own.

> I don't
> have any idea where the other threads came from.  Presumably at least one=
 of
> them was created by Glib.
>=20
> The situation is similar with emacs-w32 and emacs-nox, but with fewer thr=
eads.
>=20
> In general, is there a way I can understand where all the threads come fr=
om?

There's no simple generic way to do that, afaik.

One big problem is to have all the symbols.  You should definitely
install the debuginfo packages of all potentially affected packages, not
only cygwin-debuginfo.  If you want to find out where threads are called
from the application, you might get a clue by running emacs under GDB and
set a breakpoint to pthread_create.

Unless, of course, any component starts threads by calling the Windows
function CreateThread.  There's no guarantee that Cygwin's thread
handling will catch these, even though it tries.

> My reason for asking is that we're still getting emacs bug reports on 64-=
bit
> Cygwin, with random crashes or assertion violations that are "impossible"
> according to the gdb backtraces. [*]  So I'm wondering whether they're
> caused by interference from other threads.
>=20
> Or is there some other plausible explanation for "impossible" crashes?  T=
his
> can't just be a result of a gdb bug, because in at least one case the
> assertion can be shown to be valid by using printf instead of gdb.

One of the headaches when porting is sometimes the ABI.  While on Linux
the first 6 arguments to a function are given in registers, on Windows
only 4 args are in registers.  This can result in bugs when calling
functions with more than 4 parameters, which are invisible on Linux, due
to the way 32 bit parameter are stored in registers on x86_64.  This
happened to us already for at least one package.

Other than that, it could be a bug in any of the affected components,
including Cygwin.  I'm sorry, but I don't even have a tang of a hunch,
even after reading the emacs bugreport entries :(


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--MGYHOYXEY6WxJCY8
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJURTusAAoJEPU2Bp2uRE+gxXAP/j+tjT0ibQkkUu6MaivPlozQ
kCLEe/5ZwGjYlemgOieJLsd3Kf1XD/nn1sv9HqVUadgk57LoY9UGxZcj1lnZFBfW
LFxf8i1mg8YT9eIsW2POtDS5akozA/KpluaZ5ci9BHfak+CdFHtChXnry3CybxlY
4KNgNgEpA2JJKOa5x+2HeyartBphvlHPfnt/V2g9Gg6U5oOHrsiuVGAYdZxFlxXQ
DFJ4hFJBTUm2W8Cd/9BNvnssCIKYh/v87hq/M07P3FJ6tpcBJ+knHOhNlz6POrhi
1PYIYsgSUcJtCZDlzxHWxZXBMogPCansMTDxwXB8y8qJbKLgbFydLLjMSTiyh07c
aGBZWUkbHD2hbOEaOAEB+KmUWyRAO8mrBp9/lzQAYmSmPSplXOaIrLNT/ItE+2Hw
CZD/QzBiSnZtcciwLmFs5sJDexJxVMTwLtvDAZlquUYb1iS7NoySrytFY4tg5kpk
egZMXjSMy2QMdyAWU0L2UZmz/m3v+rJJgZWAmauXz9hqSkkL4TCO9mXXshNQLf0x
D2PGbnaCJDxGXAakr0bPQ9iYG3NahOkHXSbz/DZ24v1yZqJaAQMHsfRFzF7RJcdU
qIXHjUnSX1T07pe+Lh/kDSpbeniaqz/rCpehQfI77Q9rx75p8mH1PFK8Om6OUtF1
EW8v+8smMcdBQ2B7zB1N
=Ulj4
-----END PGP SIGNATURE-----

--MGYHOYXEY6WxJCY8--