This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
- From: Pedro Alves <palves at redhat dot com>
- To: Wei-min Pan <weimin dot pan at oracle dot com>, Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 16 Mar 2017 17:08:33 +0000
- Subject: Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
- Authentication-results: sourceware.org; auth=none
- 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 at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B9E60804ED
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B9E60804ED
- References: <1488338603-107524-1-git-send-email-weimin.pan@oracle.com> <868to5mgam.fsf@gmail.com> <58CAB698.7040602@oracle.com>
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