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=JRmvRvwKSp4ipRqPH33EfZ7wsdlP0bwqfOi1KPfGPdyQTKWNME0ps
	QJ6Dmzb+lqEPwxAgaUjMj3+4VH3x3Dku761oaRuTOOMb9h/YR9xnTEj+WbkxERZv
	IDeL6orgO+z8oVKCETUdcwUpgHqCl5J/mjclA5s6qvzvwuiwGW+Lfw=
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: Sat, 20 Jun 2015 20:47:15 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: gdb arbitrarily starting threads
Message-ID: <20150620184715.GA17350@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CAH5rLZVsTzSVTRzG_Aucw=_i-o5M-G0_ddPu0gPaqQM-Nn3iJg AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ"
Content-Disposition: inline
In-Reply-To: <CAH5rLZVsTzSVTRzG_Aucw=_i-o5M-G0_ddPu0gPaqQM-Nn3iJg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Jun 20 09:29, William M. (Mike) Miller wrote:
> I have a single-threaded executable that has a number of debug-print
> routines that can be called interactively in the debugger to display
> data structures to stderr.  Something has changed in gdb/gcc/Cygwin
> during the last year or so (I don't update my installation very often)
> so that when I call one of these functions, _sometimes_ gdb will start
> a new thread and put my current thread into "running" status, so that
> I can't step, etc. (although the thread isn't actually running).
> Here's the scenario:
>=20
> 1) I say "gdb xxx.exe", set a breakpoint, and run.  When I hit the
> breakpoint, "info threads" shows me two threads, one for my executable
> and one with some _cygtls/cygthread/ntdll frames; both are stopped.
>=20
> 2) I say "up" a couple of times, then "p db_foo(p)" (where db_foo is
> one of these debug-print routines that displays to stderr the data
> structure pointed to by "p").  Sometimes, but not always, gdb will
> respond with
>=20
>     [New Thread 1436.0x1f00]

You don't have this under control.  Nor does Cygwin, most of the time.

E.g, a debugged Windows executable has always at least two threads, one
is your process thread, one is the thread created by the OS when the
debugger attaches to a process.

Every Cygwin process has at least two threads, your process thread, as
well as a so-called "signal thread", the thread handling POSIX signals,
created at every process startup by the Cygwin DLL.

Certain Windows system calls create threads in your process to perform
tasks "under the hood".

Cygwin is doing the same, for instance to implement interruptible system
calls where the underlying OS call is non-interuptible.  select(2) may
start multiple threads at once.  Etc.

There's no way around that.  Windows process handling is centered around
cheap thread creation and termination.  Have a look into the "Details"
view in Windows Task Manager.  Activate the "Threads" column.  Note that
almost all processes are running with more than one thread.  Just don't
worry about it, it's kind of system inherent.


Corinna

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

--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVhbUzAAoJEPU2Bp2uRE+g9sYP/0ksBGphlJZIrL8ks+je8kTV
TSpSuKJPCcuJh8oYfLNRE3LCBMZvOgc17kZV0I3aBoiAaS6FdXMAe6Bu04xIqYhC
LCp/q9j0cQQxy73bqZP2y+bHa10SbhCTQ8ODaB8UyQSM4ISVmzhibFFq2BPiYyMB
Hz+VmWsyYo4AKXZXLbUmPO48+fzbxy3Ry56tVgiu7TYXra8vQZuUEULeUoInLbYC
PhjfvYbY2iXPrcK9Is0tOLOedmbKxtF7IjXWAlHccFgcpjbNNIPz+KvTTAH58Cxc
QEqx2AoCXvMIkfX02sRrwRi6qTAYmUbqC9a589VWwyDsdqoErWOjMqhAStKHr7tH
zyq+/YznPi+plluwtHs82Y6t0YIfuRpRUqqskKObZygKpPyPVm4r4gKE+EaAo/8c
+oEEHd3Us1edp7q9/3QEXE7FkevO6J1pxYc6N50/R+Sdizo4Lg9BJofEIrC8T4ao
0Lh+3ihMvHKs/GjxD63NxKJ+ctgczdyUNQLD3GUeIMRWmH1/exXr3ubsuq8v1c8O
rHQO05H2ofi2hbFjzKnIE1PUzVkbTHxLNBSGQ4nqLEVoKiCSj9dUyahjxsqDHtO4
NQ/pYBZX1LYsy6L3ihbdWfMLYcR08ckHf0V7CG1Brp/eQ9rHdS5LnsAKMbz32SUL
U7BPsBA6UOpGAYyDwxbL
=CTD0
-----END PGP SIGNATURE-----

--mP3DRpeJDSE+ciuQ--