From patchwork Mon Sep 18 18:41:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Arnez X-Patchwork-Id: 22926 Received: (qmail 91049 invoked by alias); 18 Sep 2017 18:44:02 -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 91018 invoked by uid 89); 18 Sep 2017 18:44:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:2246 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Sep 2017 18:44:00 +0000 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8IIddW3036130 for ; Mon, 18 Sep 2017 14:43:59 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 2d2dakr8pn-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 18 Sep 2017 14:43:59 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 18 Sep 2017 19:43:57 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 18 Sep 2017 19:43:56 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v8IIht7020709502 for ; Mon, 18 Sep 2017 18:43:55 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E2DB7A4053 for ; Mon, 18 Sep 2017 19:39:58 +0100 (BST) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C8A63A404D for ; Mon, 18 Sep 2017 19:39:58 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.164]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP for ; Mon, 18 Sep 2017 19:39:58 +0100 (BST) From: Andreas Arnez To: gdb-patches@sourceware.org Subject: [PATCH 2/2] GDB test suite: Get core files on targets with systemd-coredump Date: Mon, 18 Sep 2017 20:41:52 +0200 In-Reply-To: <1505760152-28775-1-git-send-email-arnez@linux.vnet.ibm.com> References: <1505760152-28775-1-git-send-email-arnez@linux.vnet.ibm.com> X-TM-AS-GCONF: 00 x-cbid: 17091818-0040-0000-0000-000003DADC95 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17091818-0041-0000-0000-000025DC095C Message-Id: <1505760152-28775-3-git-send-email-arnez@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709180264 X-IsSubscribed: yes So far the test suite skips tests if they need system-generated core files and the core files can not be found. In particular this is usually the case on systems with an active systemd-coredump service. On such systems, core files are not written into the local directory, but made accessible via a command-line utitily "coredumpctl" instead. This patch enables processing core files on such systems as well. Note that there are a few quirks: * In my tests, after invoking a command that dumps core, it could happen that "coredumpctl" did not find the dump immediately afterwards. After waiting a bit, the dump was found and could be accessed. Thus the patch performs a single wait-and-retry in case of failure. * There does not seem to be a way for a user to remove specific core dumps from the journal. Thus it can happen that "coredumpctl" returns an old dump, and the test case continues with that instead of the new one. It might be possible to improve the logic here, by considering the time stamps as well. I leave that for a future patch. * On the system I've tested it on, the bigcore.exp test case still failed because coredumpctl truncated the core file after 4G for some reason. gdb/testsuite/ChangeLog: * lib/gdb.exp (find_core): Add handling for targets with systemd-coredump, using the coredumpctl command. --- gdb/testsuite/lib/gdb.exp | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 1fd0009..7f80e12 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -5877,6 +5877,19 @@ proc find_core {binfile coredir {destcore ""}} { } } + # We may be running on a system with the systemd-coredump service in + # effect; try the coredumpctl command. But due to asynchronous + # processing the core dump may not have been processed yet. Thus wait + # a bit and retry after failure. + foreach delay {0 1} { + sleep $delay + if {![catch {exec -ignorestderr coredumpctl -o $destcore dump $binfile}]} { + if [file exists $destcore] { + return $destcore + } + } + } + warning "Can not locate core dump generated by \"[file tail $binfile]\"." return "" }