From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82594 invoked by alias); 16 Mar 2017 17:08:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 82583 invoked by uid 89); 16 Mar 2017 17:08:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*f:sk:58CAB69, H*MI:sk:58CAB69, Hx-languages-length:1021, H*i:sk:58CAB69 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Mar 2017 17:08:36 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B9E60804ED; Thu, 16 Mar 2017 17:08:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B9E60804ED Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B9E60804ED Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id D1F195DD62; Thu, 16 Mar 2017 17:08:35 +0000 (UTC) Subject: Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command To: Wei-min Pan , Yao Qi References: <1488338603-107524-1-git-send-email-weimin.pan@oracle.com> <868to5mgam.fsf@gmail.com> <58CAB698.7040602@oracle.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Thu, 16 Mar 2017 17:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <58CAB698.7040602@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00280.txt.bz2 On 03/16/2017 04:00 PM, Wei-min Pan wrote: > Yao Qi wrote: >> Did you see timeout fails in all gcore related tests? gdb_gcore_cmd is >> used in many places in gdb testsuite. Did you investigate why it is so >> slow to generate coredump in gdb? >> >> > No, only this test failed with timeout and did so consistently. The > generated core file was fine. > We suspect the slow disk performance was the culprit. I agree with Yao, and I'm not convinced. The generated core file is just "8.6M" on my x86_64 Fedora 23 and the test runs in under 1s here. $ time make check TESTS="*/siginfo-thread.exp" ... real 0m0.781s user 0m0.554s sys 0m0.152s What's the size of the core you get? If you run the test manually, do we notice any kind of slowness? If you have a general slowness issue in your testing host, then this should be affecting all gcore tests the same. We have some tests that generate big cores on purpose even. Thanks, Pedro Alves