From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110610 invoked by alias); 14 Mar 2015 16:15:09 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 110597 invoked by uid 89); 14 Mar 2015 16:15:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 14 Mar 2015 16:15:07 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 60CAF18AEB8; Sat, 14 Mar 2015 16:15:06 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2EGF4wk009303; Sat, 14 Mar 2015 12:15:05 -0400 Message-ID: <55045E87.4040100@redhat.com> Date: Sat, 14 Mar 2015 16:15:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eli Zaretskii CC: gdb@sourceware.org Subject: Re: Inadvertently run inferior threads References: <83h9tq3zu3.fsf@gnu.org> <55043A63.6020103@redhat.com> <8361a339xd.fsf@gnu.org> <5504555C.804@redhat.com> <83385736qt.fsf@gnu.org> In-Reply-To: <83385736qt.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00038.txt.bz2 On 03/14/2015 04:04 PM, Eli Zaretskii wrote: >> Date: Sat, 14 Mar 2015 15:35:56 +0000 >> From: Pedro Alves >> CC: gdb@sourceware.org >> >>> In that case, the cause of it getting out of sync is the new thread >>> that was started (probably by Windows)? >> >> Calling a function that ends up starting new threads should >> work OK, but indeed that seems to be broken... > > Yes, but in my case the called function didn't really start any > threads... If emacs doesn't start a new thread directly, it just looks to me that some Windows API function internally spawns them sometimes, then? From gdb's perspective, it's exactly the same thing, it's all code in the inferior. > > That said, thanks for the info, it could very well be relevant. > >> (gdb) info threads >> Id Target Id Frame >> 2 Thread 0x7ffff7fc1700 (LWP 9903) "start-thread-in" (running) >> * 1 Thread 0x7ffff7fc2740 (LWP 9899) "start-thread-in" main () at start-thread-infcall.c:35 > > What does "start-thread-in" signify in this display? It's the thread name, which defaults to the binary's file name name, which was "start-thread-infcall", but Linux trims it to 15 or so characters, IIRC. For this to work, you need to implement the target_thread_name hook. AFAICS, only linux-nat.c implements this. Thanks, Pedro Alves