This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] gdb.base/siginfo-thread.exp: Increase timeout for 'gcore' command


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]