From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20329 invoked by alias); 16 Mar 2017 18:34:59 -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 20318 invoked by uid 89); 16 Mar 2017 18:34:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=H*RU:!192.168.0.101!, H*i:sk:58CAD90, H*f:sk:58CAD90, Hx-spam-relays-external:!192.168.0.101! X-HELO: mail-wr0-f180.google.com Received: from mail-wr0-f180.google.com (HELO mail-wr0-f180.google.com) (209.85.128.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Mar 2017 18:34:57 +0000 Received: by mail-wr0-f180.google.com with SMTP id l37so38122646wrc.1 for ; Thu, 16 Mar 2017 11:34:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tMPiXEXdnU1Di2yVUg5fhmGI6T0/BIde8v6k4IyF4Fg=; b=WbQbWYpNHOSr6KZee38DL2I3KKKAyc5xyouVLzT0nfSwplK8jpV/y5Bf2E/zgoDcvv JxtBPw9+Fr63Q0buqS8sSFHB7CVl6Bwk5nEvtz8eEn6Oz8ceHcrOfA277vKKhXHiQv4W FQVXdnCXaPBkWZnbvHKGN3VD/i0rfId6xbKziMf7Z0QDOc9wOsbADem6VXvtBSeYZKOb qAHpJl9/Iyh+enDV1olVprqCZ/Vbm4tr410rZcoR7haDEfNXbLSHmYpNzH1EJIUnNOtz LCdhj53lkCD4OQNN0/B9cY0MF9loOCLQfr5XP1V6i9w+kqxxgkSwsP+9Uln7RXnngtE1 TEDg== X-Gm-Message-State: AFeK/H2XTvwe9lIGYlfVF8JT5PJsNlNzCGcwWAVRDdtHsn1ehzv7BEG/XOXJMFrB0/LPLGjl X-Received: by 10.223.165.74 with SMTP id j10mr8844354wrb.143.1489689296591; Thu, 16 Mar 2017 11:34:56 -0700 (PDT) Received: from [192.168.0.101] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id c9sm5224109wmf.18.2017.03.16.11.34.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 11:34:55 -0700 (PDT) Subject: Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command To: Wei-min Pan References: <1488338603-107524-1-git-send-email-weimin.pan@oracle.com> <868to5mgam.fsf@gmail.com> <58CAB698.7040602@oracle.com> <58CAD90A.40809@oracle.com> Cc: Yao Qi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <46433bf1-c3a6-d2fc-c6b3-1cfe21553a87@redhat.com> Date: Thu, 16 Mar 2017 18:34: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: <58CAD90A.40809@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00289.txt.bz2 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? >> 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