From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8143 invoked by alias); 16 Mar 2017 18:27:30 -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 8134 invoked by uid 89); 16 Mar 2017 18:27:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=90m, 90M, H*f:sk:58CAB69, Wei-min X-HELO: aserp1040.oracle.com Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Mar 2017 18:27:28 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2GIROqE023181 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Mar 2017 18:27:25 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v2GIROgj005128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Mar 2017 18:27:24 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v2GIROfu019889; Thu, 16 Mar 2017 18:27:24 GMT Received: from [10.154.104.136] (/10.154.104.136) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Mar 2017 11:27:23 -0700 Message-ID: <58CAD90A.40809@oracle.com> Date: Thu, 16 Mar 2017 18:27:00 -0000 From: Wei-min Pan User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Pedro Alves CC: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command References: <1488338603-107524-1-git-send-email-weimin.pan@oracle.com> <868to5mgam.fsf@gmail.com> <58CAB698.7040602@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00288.txt.bz2 Pedro Alves wrote: > 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? > The core size is a little over 9.0M but it took much longer to run this individual test: % time make check TESTS="*/siginfo-thread.exp" ... real 0m11.743s user 0m3.892s sys 0m7.572s And I didn't notice any slowness if the test was run by hand. > 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. > Like I said, only this test consistently failed and the core file generated was not that big. Thanks. > Thanks, > Pedro Alves > >