From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13099 invoked by alias); 10 Jun 2015 15:33:18 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 13060 invoked by uid 48); 10 Jun 2015 15:33:16 -0000 From: "eliz at gnu dot org" To: gdb-prs@sourceware.org Subject: [Bug threads/18127] threads spawned by infcall end up stuck in "running" state Date: Wed, 10 Jun 2015 15:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: threads X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: eliz at gnu dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-q2/txt/msg00403.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=18127 Eli Zaretskii changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eliz at gnu dot org --- Comment #4 from Eli Zaretskii --- On MS-Windows during native MinGW debugging, this issue, when it happens, makes the debugging session unusable. MinGW native debugging doesn't support async execution, and therefore there's no command to stop the threads that GDB considers "running", nor help GDB re-synchronize its notion of thread states with the actual situation (which of course is that the threads are all suspended by the OS). Unlike in the examples brought here from Unix and GNU systems, I see this on Windows when I call functions from the inferior. Those functions don't start any threads; the threads that trigger the problem are started by Windows for reasons unknown to me. And because in Windows native debugging the set_running function is called with minus_one_ptid, it marks all the threads as running. This isan acute problem that needs to be solved at least for the above configuration. -- You are receiving this mail because: You are on the CC list for the bug.