From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-44205-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 92075 invoked by alias); 14 Mar 2015 16:04:55 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Received: (qmail 92056 invoked by uid 89); 14 Mar 2015 16:04:54 -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,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2
X-HELO: mtaout22.012.net.il
Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 14 Mar 2015 16:04:53 +0000
Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NL700I00LPDX500@a-mtaout22.012.net.il> for gdb@sourceware.org; Sat, 14 Mar 2015 18:04:50 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NL700IAKM02MKA0@a-mtaout22.012.net.il>; Sat, 14 Mar 2015 18:04:50 +0200 (IST)
Date: Sat, 14 Mar 2015 16:04:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: Inadvertently run inferior threads
In-reply-to: <5504555C.804@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb@sourceware.org
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <83385736qt.fsf@gnu.org>
References: <83h9tq3zu3.fsf@gnu.org> <55043A63.6020103@redhat.com> <8361a339xd.fsf@gnu.org> <5504555C.804@redhat.com>
X-IsSubscribed: yes
X-SW-Source: 2015-03/txt/msg00036.txt.bz2

> Date: Sat, 14 Mar 2015 15:35:56 +0000
> From: Pedro Alves <palves@redhat.com>
> 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...

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?