From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112675 invoked by alias); 16 Mar 2017 19:10:26 -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 112652 invoked by uid 89); 16 Mar 2017 19:10:25 -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 autolearn=no version=3.3.2 spammy=H*f:sk:58CAD90, H*f:sk:46433bf, H*i:sk:46433bf, H*MI:sk:46433bf 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 19:10:24 +0000 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2GJAKh0017910 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Mar 2017 19:10:21 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v2GJAKDc008382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Mar 2017 19:10:20 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v2GJAIfU008917; Thu, 16 Mar 2017 19:10:19 GMT Received: from [10.154.104.136] (/10.154.104.136) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Mar 2017 12:10:18 -0700 Message-ID: <58CAE319.1030807@oracle.com> Date: Thu, 16 Mar 2017 19:10: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> <58CAD90A.40809@oracle.com> <46433bf1-c3a6-d2fc-c6b3-1cfe21553a87@redhat.com> In-Reply-To: <46433bf1-c3a6-d2fc-c6b3-1cfe21553a87@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00292.txt.bz2 Pedro Alves wrote: > On 03/16/2017 06:27 PM, Wei-min Pan wrote: > >> 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. >> > > You mean that by hand it went faster than that? > So what is GDB doing differently when run via make check > that makes it slower than running by hand? > Yes, but not by much faster: % cat in run gcore tmp.gcore quit % time my_gdb siginfo-thread -x in ... real 0m13.327s user 0m3.504s sys 0m7.572s Thanks. > >>> 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. >> > > Which suggests bumping the timeout is not the right thing to do. > > Thanks, > Pedro Alves > >