* [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
@ 2017-03-01 3:23 Weimin Pan
2017-03-16 14:45 ` Yao Qi
0 siblings, 1 reply; 9+ messages in thread
From: Weimin Pan @ 2017-03-01 3:23 UTC (permalink / raw)
To: gdb-patches
The following failed lines from running test case siginfo-thread:
FAIL: gdb.base/siginfo-thread.exp: save a core file (timeout)
FAIL: gdb.base/siginfo-thread.exp: extract si_addr
FAIL: gdb.base/siginfo-thread.exp: p ssi_addr
indicate the testsuite timed out when gdb was instructed to write the
core file. The patch below fixes the problem by simply increasing the
timeout by a factor of 2 to give gdb more time to generate core files.
Tested in sparc64-linux-gnu. No regressions.
gdb/testsuite/ChangeLog:
2017-02-22 Weimin Pan <weimin.pan@oracle.com>
* gdb.base/siginfo-thread.exp: Increase timeout by a factor of 2
for the 'gcore command.
---
gdb/testsuite/gdb.base/siginfo-thread.exp | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/gdb/testsuite/gdb.base/siginfo-thread.exp b/gdb/testsuite/gdb.base/siginfo-thread.exp
index 825a0d2..872780b 100644
--- a/gdb/testsuite/gdb.base/siginfo-thread.exp
+++ b/gdb/testsuite/gdb.base/siginfo-thread.exp
@@ -44,15 +44,17 @@ if { ![runto_main] } then {
gdb_test "continue" "Thread .* received signal SIGSEGV.*" "continue to signal"
# Try to generate a core file, for a later test.
-set gcorefile [standard_output_file $testfile.gcore]
-set gcore_created [gdb_gcore_cmd $gcorefile "save a core file"]
-
-set ssi_addr ""
-set test "extract si_addr"
-gdb_test_multiple "p \$_siginfo" "$test" {
- -re "si_addr = ($hex).*$gdb_prompt $" {
- set ssi_addr $expect_out(1,string)
- pass "$test"
+with_timeout_factor 2 {
+ set gcorefile [standard_output_file $testfile.gcore]
+ set gcore_created [gdb_gcore_cmd $gcorefile "save a core file"]
+
+ set ssi_addr ""
+ set test "extract si_addr"
+ gdb_test_multiple "p \$_siginfo" "$test" {
+ -re "si_addr = ($hex).*$gdb_prompt $" {
+ set ssi_addr $expect_out(1,string)
+ pass "$test"
+ }
}
}
--
1.7.1
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
2017-03-01 3:23 [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command Weimin Pan
@ 2017-03-16 14:45 ` Yao Qi
2017-03-16 16:00 ` Wei-min Pan
0 siblings, 1 reply; 9+ messages in thread
From: Yao Qi @ 2017-03-16 14:45 UTC (permalink / raw)
To: Weimin Pan; +Cc: gdb-patches
Weimin Pan <weimin.pan@oracle.com> writes:
> The following failed lines from running test case siginfo-thread:
>
> FAIL: gdb.base/siginfo-thread.exp: save a core file (timeout)
> FAIL: gdb.base/siginfo-thread.exp: extract si_addr
> FAIL: gdb.base/siginfo-thread.exp: p ssi_addr
>
> indicate the testsuite timed out when gdb was instructed to write the
> core file. The patch below fixes the problem by simply increasing the
> timeout by a factor of 2 to give gdb more time to generate core files.
>
> Tested in sparc64-linux-gnu. No regressions.
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?
--
Yao (齐尧)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
2017-03-16 14:45 ` Yao Qi
@ 2017-03-16 16:00 ` Wei-min Pan
2017-03-16 17:08 ` Pedro Alves
0 siblings, 1 reply; 9+ messages in thread
From: Wei-min Pan @ 2017-03-16 16:00 UTC (permalink / raw)
To: Yao Qi; +Cc: gdb-patches
Yao Qi wrote:
> Weimin Pan <weimin.pan@oracle.com> writes:
>
>
>> The following failed lines from running test case siginfo-thread:
>>
>> FAIL: gdb.base/siginfo-thread.exp: save a core file (timeout)
>> FAIL: gdb.base/siginfo-thread.exp: extract si_addr
>> FAIL: gdb.base/siginfo-thread.exp: p ssi_addr
>>
>> indicate the testsuite timed out when gdb was instructed to write the
>> core file. The patch below fixes the problem by simply increasing the
>> timeout by a factor of 2 to give gdb more time to generate core files.
>>
>> Tested in sparc64-linux-gnu. No regressions.
>>
>
> 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.
Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
2017-03-16 16:00 ` Wei-min Pan
@ 2017-03-16 17:08 ` Pedro Alves
2017-03-16 18:27 ` Wei-min Pan
0 siblings, 1 reply; 9+ messages in thread
From: Pedro Alves @ 2017-03-16 17:08 UTC (permalink / raw)
To: Wei-min Pan, Yao Qi; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
2017-03-16 17:08 ` Pedro Alves
@ 2017-03-16 18:27 ` Wei-min Pan
2017-03-16 18:34 ` Pedro Alves
0 siblings, 1 reply; 9+ messages in thread
From: Wei-min Pan @ 2017-03-16 18:27 UTC (permalink / raw)
To: Pedro Alves; +Cc: Yao Qi, gdb-patches
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
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
2017-03-16 18:27 ` Wei-min Pan
@ 2017-03-16 18:34 ` Pedro Alves
2017-03-16 19:10 ` Wei-min Pan
0 siblings, 1 reply; 9+ messages in thread
From: Pedro Alves @ 2017-03-16 18:34 UTC (permalink / raw)
To: Wei-min Pan; +Cc: Yao Qi, gdb-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
2017-03-16 18:34 ` Pedro Alves
@ 2017-03-16 19:10 ` Wei-min Pan
2017-03-16 19:21 ` Pedro Alves
0 siblings, 1 reply; 9+ messages in thread
From: Wei-min Pan @ 2017-03-16 19:10 UTC (permalink / raw)
To: Pedro Alves; +Cc: Yao Qi, gdb-patches
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
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
2017-03-16 19:10 ` Wei-min Pan
@ 2017-03-16 19:21 ` Pedro Alves
2017-03-16 19:51 ` Wei-min Pan
0 siblings, 1 reply; 9+ messages in thread
From: Pedro Alves @ 2017-03-16 19:21 UTC (permalink / raw)
To: Wei-min Pan; +Cc: Yao Qi, gdb-patches
On 03/16/2017 07:10 PM, Wei-min Pan wrote:
>> 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
Either I'm missing something, or that was _slower_ than then
number you shown of running via the testsuite, not faster...
So WDT is GDB doing that takes that long? Is that writing
the core to a slow NFS mount or something?
Here that takes:
real 0m0.120s
user 0m0.090s
sys 0m0.033s
and this is not a state-of-the-art machine.
Can you guess the next question?
Pick any other core test in the testsuite, do the
same and compare the numbers.
And if they're different, the next question would
then be, "what's different in this test, why's
it slower?".
If they're similar, then, well, the same question. :-)
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command
2017-03-16 19:21 ` Pedro Alves
@ 2017-03-16 19:51 ` Wei-min Pan
0 siblings, 0 replies; 9+ messages in thread
From: Wei-min Pan @ 2017-03-16 19:51 UTC (permalink / raw)
To: Pedro Alves; +Cc: Yao Qi, gdb-patches
Pedro Alves wrote:
> On 03/16/2017 07:10 PM, Wei-min Pan wrote:
>
>
>>> 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
>>
>
> Either I'm missing something, or that was _slower_ than then
> number you shown of running via the testsuite, not faster...
>
Sorry, you didn't miss anything. I misspoke :)
> So WDT is GDB doing that takes that long? Is that writing
> the core to a slow NFS mount or something?
>
> Here that takes:
>
> real 0m0.120s
> user 0m0.090s
> sys 0m0.033s
>
> and this is not a state-of-the-art machine.
>
> Can you guess the next question?
>
> Pick any other core test in the testsuite, do the
> same and compare the numbers.
>
> And if they're different, the next question would
> then be, "what's different in this test, why's
> it slower?".
>
OK, just tried a different test which is similar to siginfo-thread:
% time make check TESTS="*/siginfo-obj.exp"
...
real 0m1.282s
user 0m0.736s
sys 0m0.400s
Looks like the slowness had something to do with the pthread libs.
Will investigate. Thanks.
> If they're similar, then, well, the same question. :-)
>
> Thanks,
> Pedro Alves
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-03-16 19:51 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-01 3:23 [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command Weimin Pan
2017-03-16 14:45 ` Yao Qi
2017-03-16 16:00 ` Wei-min Pan
2017-03-16 17:08 ` Pedro Alves
2017-03-16 18:27 ` Wei-min Pan
2017-03-16 18:34 ` Pedro Alves
2017-03-16 19:10 ` Wei-min Pan
2017-03-16 19:21 ` Pedro Alves
2017-03-16 19:51 ` Wei-min Pan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).