From patchwork Mon Aug 13 21:45:31 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 28874 Received: (qmail 44332 invoked by alias); 13 Aug 2018 21:45:58 -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 44107 invoked by uid 89); 13 Aug 2018 21:45:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.4 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=H*RU:74.125.82.65, Hx-spam-relays-external:74.125.82.65 X-HELO: mail-wm0-f65.google.com Received: from mail-wm0-f65.google.com (HELO mail-wm0-f65.google.com) (74.125.82.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Aug 2018 21:45:40 +0000 Received: by mail-wm0-f65.google.com with SMTP id y9-v6so10281180wma.5 for ; Mon, 13 Aug 2018 14:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=zT/1TKondug30SZP7t6HZvmdS+EQBYrwm1I1SsXQt4I=; b=WNDM8y7wDAQAkN4c14JMHg8Q+9gpWGLp+VCoYmdLdrnCsswH8RrmyJvzMDXNeQpfd9 wHJMhEbi+vOC4yRVUXuW3Gk0V/18ZfzI+WAUxWE2yyC+G/a/oxcKILfzTjQLH+sfzI3g cOn1lnwwdBYFhIvkRzgcXIfb0LvDZj3MWj3IHLyKLnPUtB88RHiwjTUQ4fSKcQghxN2B rGeCxxKDlwdk7kThk8b9Q1avEz18zDbJaH6BbKxxdu0zHbFsCc7d+mVyfVuWVvjxRmy7 AdfvTcFJfkgNAgnqkkBj7TdLNPQgh5EX9IRRXJw2yBBaWqZ6fI5N0kz5zu/A5gVNEq02 41KA== Return-Path: Received: from localhost (host81-140-215-41.range81-140.btcentralplus.com. [81.140.215.41]) by smtp.gmail.com with ESMTPSA id t13-v6sm13545049wrr.74.2018.08.13.14.45.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 Aug 2018 14:45:32 -0700 (PDT) Date: Mon, 13 Aug 2018 22:45:31 +0100 From: Andrew Burgess To: Pedro Alves Cc: Simon Marchi , gdb-patches@sourceware.org Subject: [PATCHv2] gdb: Fix instability in thread groups test Message-ID: <20180813214531.GZ3155@embecosm.com> References: <20180810095750.13017-1-andrew.burgess@embecosm.com> <7da382e5-bd5e-25c2-b3f8-f38e692f35a1@redhat.com> <20180813114137.GX3155@embecosm.com> <2e47657d-b81b-497d-58bf-0463980dec24@redhat.com> <20180813130125.GY3155@embecosm.com> <7ab394a0-f796-4ff3-65e2-c7db9d7063e7@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7ab394a0-f796-4ff3-65e2-c7db9d7063e7@redhat.com> X-Fortune: Too much radiation coming from the soil. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes Here's an updated version of the patch based on previous feedback. The new version has additional comments explaining why the regexp allows an empty core list. I also only allow the empty core list when we scan all processes, its only in this case we might hit an exiting process. When we scan two known PIDs, I don't allow an empty core list. --- gdb: Fix instability in thread groups test In the test script gdb.mi/list-thread-groups-available.exp we ask GDB to list all thread groups, and match the output against a regexp. Occasionally, I would see this test fail. The expected output is a list of entries, each entry looking roughly like this: {id="",type="process",description="", user="",cores=["","",...]} All the fields after 'id' and 'type' are optional, and the 'cores' list can contain 1 or more "" entries. On my machine (Running Fedora 27, kernel 4.17.3-100.fc27.x86_64) usually the 'description' is a non-empty string, and the 'cores' list has at least one entry in it. But sometimes, very rarely, I'll see an entry in the process group list where the 'description' is an empty string, the 'user' is the string "?", and the 'cores' list is empty. Such an entry looks like this: {id="19863",type="process",description="",user="?",cores=[]} I believe that this is caused by the process exiting while GDB is scanning /proc for process information. The current code in gdb/nat/linux-osdata.c is not (I think) resilient against exiting processes. This commit adjusts the regex that matches the 'cores' list so that an empty list is acceptable, with this patch in place the test script gdb.mi/list-thread-groups-available.exp never fails for me now. I've only adjusted the cores regexp for the occasion when we have GDB read information about all processes, its only in this case that we might encounter an exiting process. When we read information about two known PIDs, that we know will not exit for the duration of the test, we require that the core list be non-empty. gdb/testsuite/ChangeLog: * gdb.mi/list-thread-groups-available.exp: Update test regexp. --- gdb/testsuite/ChangeLog | 4 ++++ gdb/testsuite/gdb.mi/list-thread-groups-available.exp | 12 +++++++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.mi/list-thread-groups-available.exp b/gdb/testsuite/gdb.mi/list-thread-groups-available.exp index c4dab2a2c34..11eddd577a3 100644 --- a/gdb/testsuite/gdb.mi/list-thread-groups-available.exp +++ b/gdb/testsuite/gdb.mi/list-thread-groups-available.exp @@ -45,7 +45,11 @@ set id_re "id=\"$decimal\"" set type_re "type=\"process\"" set description_re "description=\"$string_re\"" set user_re "user=\"$string_re\"" -set cores_re "cores=\\\[\"$decimal\"(,\"$decimal\")*\\\]" + +# The CORES_RE regexp allows a process to be running on zero or more +# cores. This can happen if a process exits while GDB is reading +# information out of /proc. +set cores_re "cores=\\\[(\"$decimal\"(,\"$decimal\")*)?\\\]" # List all available processes. set process_entry_re "{${id_re},${type_re}(,$description_re)?(,$user_re)?(,$cores_re)?}" @@ -64,6 +68,12 @@ set spawn_id_2 [remote_spawn target $binfile] set pid_2 [spawn_id_get_pid $spawn_id_2] set id_re_2 "id=\"$pid_2\"" +# Unlike the earlier CORES_RE this list must contain at least one +# core. Given that we know these processes will not exit while GDB is +# reading their information from /proc we can expect at least one core +# for each process. +set cores_re "cores=\\\[\"$decimal\"(,\"$decimal\")*\\\]" + set process_entry_re_1 "{${id_re_1},${type_re}(,$description_re)?(,$user_re)?(,$cores_re)?}" set process_entry_re_2 "{${id_re_2},${type_re}(,$description_re)?(,$user_re)?(,$cores_re)?}"