From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-prs-return-15300-listarch-gdb-prs=sources.redhat.com@sourceware.org>
Received: (qmail 20201 invoked by alias); 27 Feb 2014 15:11:42 -0000
Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-prs.sourceware.org>
List-Subscribe: <mailto:gdb-prs-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-prs/>
List-Post: <mailto:gdb-prs@sourceware.org>
List-Help: <mailto:gdb-prs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: gdb-prs-owner@sourceware.org
Received: (qmail 20172 invoked by uid 48); 27 Feb 2014 15:11:41 -0000
From: "palves at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug threads/14618] gdbserver, scheduler-locking, thread exits and
 TARGET_WAITKIND_NO_RESUMED
Date: Thu, 27 Feb 2014 15:11: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: 7.4
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: critical
X-Bugzilla-Who: palves at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-14618-4717-a42tYbyBG8@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-14618-4717@http.sourceware.org/bugzilla/>
References: <bug-14618-4717@http.sourceware.org/bugzilla/>
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: 2014-q1/txt/msg00308.txt.bz2

https://sourceware.org/bugzilla/show_bug.cgi?id=14618

--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
The hangs themselves are now fixed on GDBserver mainline.

  https://sourceware.org/ml/gdb-patches/2014-02/msg00826.html

GDBserver's Linux core now knows about TARGET_WAITKIND_NO_RESUMED, but
I've left out adding that to the RSP ("[PATCH 5/5] Add
TARGET_WAITKIND_NO_RESUMED support to the RSP" at
https://sourceware.org/ml/gdb-patches/2014-01/msg00897.html), because I worried
about races in non-stop mode.

Assume N is the new stop reply for TARGET_WAITKIND_NO_RESUMED, like in the
patch above and say, the traffic goes like this:

(no thread was resumed before #1)

GDB sends two steps in a row.

 #1 -> vCont;s:555
 #2 <- OK

(555 exits)

 #3 <- %Stop:N   (no more resumed threads left)

 #4 -> vCont;s:666
 #5 <- OK

And now GDB goes and processes #3, and mistakenly believes no thread is left
running on the target, while in fact, 666 is left running.  Sounds like we need
something else in addition to TARGET_WAITKIND_NO_RESUMED, maybe thread exit
events (active only for stepped threads, by default, for efficiency).

I'll leave this open until this is fully sorted out.

-- 
You are receiving this mail because:
You are on the CC list for the bug.