From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 402 invoked by alias); 20 Jun 2015 18:47:19 -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 381 invoked by uid 89); 20 Jun 2015 18:47:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 20 Jun 2015 18:47:17 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 681DCA807BB; Sat, 20 Jun 2015 20:47:15 +0200 (CEST) Date: Sat, 20 Jun 2015 18:47:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: gdb arbitrarily starting threads Message-ID: <20150620184715.GA17350@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-06/txt/msg00310.txt.bz2 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2265 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 Content-length: 819 -----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--