| Message ID | 20240301192750.1208030-1-thiago.bauermann@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | gdb/testsuite: Increase timeout when using read1 in gdb.base/osabi.exp | expand |
On 3/1/24 14:27, Thiago Jung Bauermann wrote: > The Linaro CI runs the GDB testsuite using the read1 tool, which > significantly increases the time it takes DejaGNU to read inferior output. > On top of that, sometimes the test machine has higher than normal load, > which causes tests to run even slower. > > Because the gdb.base/osabi.exp enables "debug arch" output, which is > somewhat verbose, it sometimes fails when running in the Linaro CI > environment. > > Fix this problem by using a timeout factor to run the test. > --- > gdb/testsuite/gdb.base/osabi.exp | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.base/osabi.exp b/gdb/testsuite/gdb.base/osabi.exp > index 9bbfff52bae8..47d5755f1584 100644 > --- a/gdb/testsuite/gdb.base/osabi.exp > +++ b/gdb/testsuite/gdb.base/osabi.exp > @@ -27,4 +27,6 @@ proc test_set_osabi_none { } { > gdb_test "set osabi none" ".*gdbarch_find_by_info: info.osabi 1 \\(none\\).*" > } > > -test_set_osabi_none > +with_read1_timeout_factor 10 { > + test_set_osabi_none > +} Hi Thiago, If it was really a case of "GDB is thinking for a long time before spewing out an answer", then I think that increasing the timeout would be the right fix (or, make GDB faster). But here, it appears that it's GDB outputting a lot of lines, and dejagnu taking some time to read it. I'm actually surprised that dejagnu times out, since it's constantly reading characters (one at a time), I would think that it would constantly reset its timeout timer. But perhaps the timeout applies to the whole gdb_test command. I don't recall, I haven't touched that in a while. Anyhow, a common way to fix this without bumping the timeout is to change the test to use a line by line approach. Typically by using gdb_test_multiple to consume one line at a time and to keep reading until the prompt is seen. The test can set a flag to indicate whether the searched-for string has been seen, and do a gdb_assert at the end. There might be some smarter ways to do this today, I'm not super up-to-date with the latest testsuite improvements. Simon
Hello Simon, Simon Marchi <simark@simark.ca> writes: > If it was really a case of "GDB is thinking for a long time before > spewing out an answer", then I think that increasing the timeout would > be the right fix (or, make GDB faster). > > But here, it appears that it's GDB outputting a lot of lines, and > dejagnu taking some time to read it. I'm actually surprised that > dejagnu times out, since it's constantly reading characters (one at a > time), I would think that it would constantly reset its timeout timer. > But perhaps the timeout applies to the whole gdb_test command. I don't > recall, I haven't touched that in a while. > > Anyhow, a common way to fix this without bumping the timeout is to > change the test to use a line by line approach. Typically by using > gdb_test_multiple to consume one line at a time and to keep reading > until the prompt is seen. The test can set a flag to indicate whether > the searched-for string has been seen, and do a gdb_assert at the end. > There might be some smarter ways to do this today, I'm not super > up-to-date with the latest testsuite improvements. Makes sense, I'll post a v2 that uses that approach. Thank you for the quick feedback!
diff --git a/gdb/testsuite/gdb.base/osabi.exp b/gdb/testsuite/gdb.base/osabi.exp index 9bbfff52bae8..47d5755f1584 100644 --- a/gdb/testsuite/gdb.base/osabi.exp +++ b/gdb/testsuite/gdb.base/osabi.exp @@ -27,4 +27,6 @@ proc test_set_osabi_none { } { gdb_test "set osabi none" ".*gdbarch_find_by_info: info.osabi 1 \\(none\\).*" } -test_set_osabi_none +with_read1_timeout_factor 10 { + test_set_osabi_none +}