From patchwork Thu May 24 10:50:38 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 27484 Received: (qmail 109567 invoked by alias); 24 May 2018 10:50:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 109316 invoked by uid 89); 24 May 2018 10:50:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=wasting, hang, hung, Tell X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 May 2018 10:50:48 +0000 Received: by mail-wm0-f48.google.com with SMTP id a8-v6so3782066wmg.5 for ; Thu, 24 May 2018 03:50:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=nMPcpYF2rmKC9nzZXi9AYM7fBaxn99McnsnGo8XwOqU=; b=LHF6aGuGksifEMncp7qJzlGC6d+rYM27ZW7Aj/pvrBSUz5j/W+8plQXFww9/cPbD8/ H3IkJRmGyd3s03Z0meA9MgJvWaA6/9MPSvCHkHyNL60Kyf2SVZ6z9NnRyAAsT7yi2Zd6 +ZhZe6yVCmypA2pIrAiGUsBaNs+LfZfeoeRpI1fqlxuMefX62/j3ZcELnLtIQUTSK3xs R256qkFgKtYtNuLtRQI/x8t1F1a2jYMDrx/uqzR3/0c5AJwYsZYUkfM1JKejvUx8V/Ox zvY1Bqht6Mw7se8s21rBSM6G3KWCJcUxq3hcEVAx79i/TruCKgLM9d67XzBH6DPQRTKE FY+g== X-Gm-Message-State: ALKqPwe0g2I7tYMupPRatIbk7rLDb81oPHc0KrGp94ns97qNuv8mza0+ 3ijUnleAoqJ9RpLdXe7wy5GiRSrv X-Google-Smtp-Source: AB8JxZpu8gd4Y0xVAhwU5RZdD/yDQXZjyWyZylZzAxCPi9TWXYOGbvVwvH//V0zPoEgfay4FT2ey3w== X-Received: by 2002:a1c:551:: with SMTP id 78-v6mr6510897wmf.60.1527159046446; Thu, 24 May 2018 03:50:46 -0700 (PDT) Received: from localhost (host86-164-85-144.range86-164.btcentralplus.com. [86.164.85.144]) by smtp.gmail.com with ESMTPSA id r10-v6sm10453301wrn.6.2018.05.24.03.50.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 24 May 2018 03:50:45 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH 2/4] gdb: Mark async event handler when event is already pending Date: Thu, 24 May 2018 11:50:38 +0100 Message-Id: <503564b426fd6c55391c19c9def9658e89450454.1527157948.git.andrew.burgess@embecosm.com> In-Reply-To: References: In-Reply-To: References: X-IsSubscribed: yes In PR22882 inferior functions are called on different threads while scheduler-locking is turned on. This results in a hang. This was discussed in this mailing list thread: https://sourceware.org/ml/gdb/2017-10/msg00032.html The problem is that when the thread is set running in order to execute the inferior call, a call to target_async is made. If the target is not already registered as 'target_async' then this will install the async event handler, AND unconditionally mark the handler as having an event pending. However, if the target is already regitered as target_async then the event handler is not installed (its already instealled) and the handler is NOT marked as having an event pending. If we try to set running a thread that already has a pending event, then we do want to set target_async, however, there will not be an external event incoming (the thread is already stopped) so we rely on manually marking the event handler as having a pending event in order to see the threads pending stop event. This is fine, if, at the point where we call target_async, the target is not already marked as async. But, if it is, then the event handler will not be marked as ready, and the threads pending stop event will never be processed. A similar pattern of code can be seen in linux_nat_target::resume, where, when a thread has a pending event, the call to target_async is followed by a call to async_file_mark to ensure that the pending thread event will be processed, even if target_async was already set. gdb/ChangeLog: PR gdb/22882 * infrun.c (resume_1): Add call to mark_async_event_handler. gdb/testsuite/ChangeLog: * gdb.threads/multiple-successive-infcall.exp: Remove kfail case, rewrite test to describe action performed, rather than possible failure. --- gdb/ChangeLog | 6 ++++++ gdb/infrun.c | 6 +++++- gdb/testsuite/ChangeLog | 7 +++++++ gdb/testsuite/gdb.threads/multiple-successive-infcall.exp | 15 ++------------- 4 files changed, 20 insertions(+), 14 deletions(-) diff --git a/gdb/infrun.c b/gdb/infrun.c index f86b2aa1c1a..1c4cd55e8f3 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -2408,7 +2408,11 @@ resume_1 (enum gdb_signal sig) tp->suspend.stop_signal = GDB_SIGNAL_0; if (target_can_async_p ()) - target_async (1); + { + target_async (1); + /* Tell the event loop we have an event to process. */ + mark_async_event_handler (infrun_async_inferior_event_token); + } return; } diff --git a/gdb/testsuite/gdb.threads/multiple-successive-infcall.exp b/gdb/testsuite/gdb.threads/multiple-successive-infcall.exp index a71f991d6f2..bb92c1d487d 100644 --- a/gdb/testsuite/gdb.threads/multiple-successive-infcall.exp +++ b/gdb/testsuite/gdb.threads/multiple-successive-infcall.exp @@ -56,17 +56,6 @@ gdb_test "show scheduler-locking" \ foreach_with_prefix thread {5 4 3 2 1} { gdb_test "thread ${thread}" "Switching to .*" - set command "call get_value()" - set hang_message "testing if ${command} hangs" - gdb_test_multiple "${command}" "${hang_message}" { - -re "= ${thread}\[\r\n]+${gdb_prompt} $" { - pass "${hang_message}" - } - timeout { - kfail "gdb/22882" "${hang_message}" - # Exit. The debugger has hung, so there is no point in wasting - # time timing out on further calls to get_value(). - return 0 - } - } + gdb_test "call get_value()" "= ${thread}" \ + "call inferior function" }