delorie.com/archives/browse.cgi | search |
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=JRmvRvwKSp4ipRqPH33EfZ7wsdlP0bwqfOi1KPfGPdyQTKWNME0ps | |
QJ6Dmzb+lqEPwxAgaUjMj3+4VH3x3Dku761oaRuTOOMb9h/YR9xnTEj+WbkxERZv | |
IDeL6orgO+z8oVKCETUdcwUpgHqCl5J/mjclA5s6qvzvwuiwGW+Lfw= | |
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=KE6VEGg4utl8z538ZkyUSSzHudY=; b=rpcp/R0r0n23P2CrO39xiwkEBOrN | |
Iqmw3VCMB1vgYXX5OSkpZ4kecc+1XmbdmejUwRVHbwl0MU/e+1uJOMKZtTayLHLF | |
sm0COHRKgkk/TyrrdjtDPrCyCm0rWlku2HazGZHlg9e3BUGvsjlJ5J3WnVNWhzTu | |
WNr4DNeNaT3urOY= | |
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=-4.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 |
X-HELO: | calimero.vinschen.de |
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 |
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--
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |