* [PATCH] gdb.gdb/python-helper.exp: Increase timeout values @ 2026-09-06 4:01 Thiago Jung Bauermann 2026-09-06 15:58 ` Tom de Vries 2026-09-06 18:52 ` Simon Marchi 0 siblings, 2 replies; 6+ messages in thread From: Thiago Jung Bauermann @ 2026-09-06 4:01 UTC (permalink / raw) To: gdb-patches In the three Linux machines I tested (my x86_64 laptop and two aarch64 servers), gdb.gdb/python-helper.exp has this timeout failure: FAIL: gdb.gdb/python-helper.exp: pretty print type instance flags (timeout) And the slower aarch64 server also has this one: FAIL: gdb.gdb/python-helper.exp: start inner gdb (timeout) Fix these failures by using timeout factors. For the latter, a 2x factor is enough. For the former, I needed 8x. It appears that the "pretty print type instance flags" test is quite demanding. --- I actually noticed these failures because I compared GDB 17.2 test results with GDB 18 ones. OK to also push to the branch? gdb/testsuite/gdb.gdb/python-helper.exp | 40 ++++++++++++++----------- 1 file changed, 22 insertions(+), 18 deletions(-) diff --git a/gdb/testsuite/gdb.gdb/python-helper.exp b/gdb/testsuite/gdb.gdb/python-helper.exp index d84e48166995..bcd94b2e6ae5 100644 --- a/gdb/testsuite/gdb.gdb/python-helper.exp +++ b/gdb/testsuite/gdb.gdb/python-helper.exp @@ -91,19 +91,21 @@ proc test_python_helper {} { # little clearer when trying to unpick which GDB is active. gdb_test_no_output -prompt $outer_prompt_re "set prompt (outer-gdb) " "set outer gdb prompt" - # Send a command to the outer GDB to continue the inner GDB. The - # stop is being detected from the inner GDB, hence the use of -i - # here. - gdb_test_multiple "continue" "start inner gdb" { - -re "received signal SIGSEGV.* in GC_.*$outer_prompt_re" { - # Some versions of the GC used by Guile cause a SEGV - # during stack probing. Ignore this and carry on. - send_gdb "continue\n" - exp_continue - } - -i "$inferior_spawn_id" - -re "\r\n$gdb_prompt $" { - pass $gdb_test_name + with_timeout_factor 2 { + # Send a command to the outer GDB to continue the inner GDB. The + # stop is being detected from the inner GDB, hence the use of -i + # here. + gdb_test_multiple "continue" "start inner gdb" { + -re "received signal SIGSEGV.* in GC_.*$outer_prompt_re" { + # Some versions of the GC used by Guile cause a SEGV + # during stack probing. Ignore this and carry on. + send_gdb "continue\n" + exp_continue + } + -i "$inferior_spawn_id" + -re "\r\n$gdb_prompt $" { + pass $gdb_test_name + } } } @@ -172,11 +174,13 @@ proc test_python_helper {} { " int_stuff = \{ bit_size = $decimal, bit_offset = $decimal \}\}"] gdb_test -prompt $outer_prompt_re "print *val->m_type->main_type" $answer "pretty print type->main_type" - # Test printing instance flags using an artificial type. - set answer [string_to_regexp {instance_flags = [VOLATILE|DATA_SPACE|ADDRESS_CLASS(3)]}] - gdb_test -prompt $outer_prompt_re \ - "print *make_type_with_harvard_address_space (make_cv_type (0, 1, make_type_with_address_class (val->m_type, 3)), 2)" \ - "${answer}.*" "pretty print type instance flags" + with_timeout_factor 8 { + # Test printing instance flags using an artificial type. + set answer [string_to_regexp {instance_flags = [VOLATILE|DATA_SPACE|ADDRESS_CLASS(3)]}] + gdb_test -prompt $outer_prompt_re \ + "print *make_type_with_harvard_address_space (make_cv_type (0, 1, make_type_with_address_class (val->m_type, 3)), 2)" \ + "${answer}.*" "pretty print type instance flags" + } # Send the continue to the outer GDB, which resumes the inner GDB, # we then detect the prompt from the inner GDB, hence the use of ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values 2026-09-06 4:01 [PATCH] gdb.gdb/python-helper.exp: Increase timeout values Thiago Jung Bauermann @ 2026-09-06 15:58 ` Tom de Vries 2026-09-06 20:13 ` Thiago Jung Bauermann 2026-09-06 18:52 ` Simon Marchi 1 sibling, 1 reply; 6+ messages in thread From: Tom de Vries @ 2026-09-06 15:58 UTC (permalink / raw) To: Thiago Jung Bauermann, gdb-patches On 9/6/26 6:01 AM, Thiago Jung Bauermann wrote: > In the three Linux machines I tested (my x86_64 laptop and two aarch64 > servers), gdb.gdb/python-helper.exp has this timeout failure: > > FAIL: gdb.gdb/python-helper.exp: pretty print type instance flags (timeout) > > And the slower aarch64 server also has this one: > > FAIL: gdb.gdb/python-helper.exp: start inner gdb (timeout) > > Fix these failures by using timeout factors. For the latter, a 2x factor > is enough. For the former, I needed 8x. It appears that the "pretty print > type instance flags" test is quite demanding. I tried to see if I could reproduce this. I ended up writing a patch ( https://sourceware.org/pipermail/gdb-patches/2026-September/230135.html ) for some timeout but I have no idea whether it's the same root cause or not. You may want to test it. Assuming it's not, LGTM. Approved-By: Tom de Vries <tdevries@suse.de> > --- > > I actually noticed these failures because I compared GDB 17.2 test > results with GDB 18 ones. OK to also push to the branch? > This makes me wonder if we're dealing with a performance regression here, but yeah, I suppose it's ok. Thanks, - Tom > gdb/testsuite/gdb.gdb/python-helper.exp | 40 ++++++++++++++----------- > 1 file changed, 22 insertions(+), 18 deletions(-) > > diff --git a/gdb/testsuite/gdb.gdb/python-helper.exp b/gdb/testsuite/gdb.gdb/python-helper.exp > index d84e48166995..bcd94b2e6ae5 100644 > --- a/gdb/testsuite/gdb.gdb/python-helper.exp > +++ b/gdb/testsuite/gdb.gdb/python-helper.exp > @@ -91,19 +91,21 @@ proc test_python_helper {} { > # little clearer when trying to unpick which GDB is active. > gdb_test_no_output -prompt $outer_prompt_re "set prompt (outer-gdb) " "set outer gdb prompt" > > - # Send a command to the outer GDB to continue the inner GDB. The > - # stop is being detected from the inner GDB, hence the use of -i > - # here. > - gdb_test_multiple "continue" "start inner gdb" { > - -re "received signal SIGSEGV.* in GC_.*$outer_prompt_re" { > - # Some versions of the GC used by Guile cause a SEGV > - # during stack probing. Ignore this and carry on. > - send_gdb "continue\n" > - exp_continue > - } > - -i "$inferior_spawn_id" > - -re "\r\n$gdb_prompt $" { > - pass $gdb_test_name > + with_timeout_factor 2 { > + # Send a command to the outer GDB to continue the inner GDB. The > + # stop is being detected from the inner GDB, hence the use of -i > + # here. > + gdb_test_multiple "continue" "start inner gdb" { > + -re "received signal SIGSEGV.* in GC_.*$outer_prompt_re" { > + # Some versions of the GC used by Guile cause a SEGV > + # during stack probing. Ignore this and carry on. > + send_gdb "continue\n" > + exp_continue > + } > + -i "$inferior_spawn_id" > + -re "\r\n$gdb_prompt $" { > + pass $gdb_test_name > + } > } > } > > @@ -172,11 +174,13 @@ proc test_python_helper {} { > " int_stuff = \{ bit_size = $decimal, bit_offset = $decimal \}\}"] > gdb_test -prompt $outer_prompt_re "print *val->m_type->main_type" $answer "pretty print type->main_type" > > - # Test printing instance flags using an artificial type. > - set answer [string_to_regexp {instance_flags = [VOLATILE|DATA_SPACE|ADDRESS_CLASS(3)]}] > - gdb_test -prompt $outer_prompt_re \ > - "print *make_type_with_harvard_address_space (make_cv_type (0, 1, make_type_with_address_class (val->m_type, 3)), 2)" \ > - "${answer}.*" "pretty print type instance flags" > + with_timeout_factor 8 { > + # Test printing instance flags using an artificial type. > + set answer [string_to_regexp {instance_flags = [VOLATILE|DATA_SPACE|ADDRESS_CLASS(3)]}] > + gdb_test -prompt $outer_prompt_re \ > + "print *make_type_with_harvard_address_space (make_cv_type (0, 1, make_type_with_address_class (val->m_type, 3)), 2)" \ > + "${answer}.*" "pretty print type instance flags" > + } > > # Send the continue to the outer GDB, which resumes the inner GDB, > # we then detect the prompt from the inner GDB, hence the use of ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values 2026-09-06 15:58 ` Tom de Vries @ 2026-09-06 20:13 ` Thiago Jung Bauermann 2026-09-07 1:02 ` Simon Marchi 0 siblings, 1 reply; 6+ messages in thread From: Thiago Jung Bauermann @ 2026-09-06 20:13 UTC (permalink / raw) To: Tom de Vries; +Cc: gdb-patches, simark Tom de Vries <tdevries@suse.de> writes: > On 9/6/26 6:01 AM, Thiago Jung Bauermann wrote: >> In the three Linux machines I tested (my x86_64 laptop and two aarch64 >> servers), gdb.gdb/python-helper.exp has this timeout failure: >> FAIL: gdb.gdb/python-helper.exp: pretty print type instance flags (timeout) >> And the slower aarch64 server also has this one: >> FAIL: gdb.gdb/python-helper.exp: start inner gdb (timeout) >> Fix these failures by using timeout factors. For the latter, a 2x factor >> is enough. For the former, I needed 8x. It appears that the "pretty print >> type instance flags" test is quite demanding. > > I tried to see if I could reproduce this. I ended up writing a patch ( > https://sourceware.org/pipermail/gdb-patches/2026-September/230135.html ) for some timeout > but I have no idea whether it's the same root cause or not. You may want to test it. > > Assuming it's not, LGTM. > > Approved-By: Tom de Vries <tdevries@suse.de> Thank you! I tested your patch. The same timeouts still happen. BUT: >> --- >> I actually noticed these failures because I compared GDB 17.2 test >> results with GDB 18 ones. OK to also push to the branch? > > This makes me wonder if we're dealing with a performance regression here, but yeah, I > suppose it's ok. And from Simon's email: > Out of curiosity, is this with GDB build at -O0 or -O2 (or something > else)? With ASan or other instrumentation? > > I am asking because if it's -O2, then it's representative of what a user > would have in their hands. If some commands take a minute to run, then > we could at least check if it's because GDB is doing something terribly > inefficient. Your responses made me realise I may be the only one seeing these timeouts, even if it's accross three machines. I found out that this is because I compile my test builds with -D_GLIBCXX_DEBUG. I hadn't realized until now that its impact on GDB performance was so big: Without -D_GLIBCXX_DEBUG on the slower aarch64 server: $ ./gdb -D data-directory -nx -q -ex 'maint set per-command time' -ex 'file gdb' -ex quit Reading symbols from gdb... Time for "minsym install worker": wall 0.237, user 0.135, sys 0.013, user+sys 0.148, 62.4 % CPU Time for "minsym install worker": wall 0.238, user 0.139, sys 0.003, user+sys 0.142, 59.7 % CPU Time for "minsym install worker": wall 0.239, user 0.141, sys 0.005, user+sys 0.146, 61.1 % CPU Time for "minsym install worker": wall 0.248, user 0.148, sys 0.009, user+sys 0.157, 63.3 % CPU Time for "minsym install worker": wall 0.249, user 0.154, sys 0.003, user+sys 0.157, 63.1 % CPU Time for "minsym install worker": wall 0.252, user 0.143, sys 0.007, user+sys 0.150, 59.5 % CPU Time for "minsym install worker": wall 0.256, user 0.151, sys 0.003, user+sys 0.154, 60.2 % CPU Time for "minsym install worker": wall 0.260, user 0.148, sys 0.004, user+sys 0.152, 58.5 % CPU ⚠ warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb line to your configuration file "/home/thiago.bauermann/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/thiago.bauermann/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". Time for "DWARF indexing worker": wall 0.623, user 0.585, sys 0.035, user+sys 0.620, 99.5 % CPU Time for "DWARF indexing worker": wall 0.623, user 0.586, sys 0.034, user+sys 0.620, 99.5 % CPU Time for "DWARF indexing worker": wall 0.623, user 0.597, sys 0.023, user+sys 0.620, 99.5 % CPU Time for "DWARF indexing worker": wall 0.623, user 0.588, sys 0.033, user+sys 0.621, 99.7 % CPU Time for "DWARF indexing worker": wall 0.625, user 0.597, sys 0.025, user+sys 0.622, 99.5 % CPU Time for "DWARF indexing worker": wall 0.625, user 0.576, sys 0.045, user+sys 0.621, 99.4 % CPU Time for "DWARF indexing worker": wall 0.626, user 0.598, sys 0.025, user+sys 0.623, 99.5 % CPU Time for "DWARF indexing worker": wall 0.626, user 0.596, sys 0.029, user+sys 0.625, 99.8 % CPU Time for "DWARF skeletonless type units": wall 0.001, user 0.001, sys 0.000, user+sys 0.001, 100.0 % CPU Time for "DWARF add parent map": wall 0.089, user 0.087, sys 0.001, user+sys 0.088, 98.9 % CPU Time for "DWARF finalize worker": wall 2.039, user 2.034, sys 0.002, user+sys 2.036, 99.9 % CPU Time for "DWARF finalize worker": wall 0.000, user 0.000, sys 0.000, user+sys 0.000, nan % CPU Time for "DWARF finalize worker": wall 2.045, user 2.040, sys 0.002, user+sys 2.042, 99.9 % CPU Time for "DWARF finalize worker": wall 2.055, user 2.051, sys 0.001, user+sys 2.052, 99.9 % CPU Time for "DWARF finalize worker": wall 2.082, user 2.077, sys 0.002, user+sys 2.079, 99.9 % CPU Time for "DWARF finalize worker": wall 2.087, user 2.082, sys 0.002, user+sys 2.084, 99.9 % CPU Time for "DWARF finalize worker": wall 2.103, user 2.096, sys 0.004, user+sys 2.100, 99.9 % CPU Time for "DWARF finalize worker": wall 2.112, user 2.107, sys 0.002, user+sys 2.109, 99.9 % CPU Time for "DWARF finalize worker": wall 2.114, user 2.110, sys 0.001, user+sys 2.111, 99.9 % CPU With -D_GLIBCXX_DEBUG on the slower aarch64 server: $ ./gdb -D data-directory -nx -q -ex 'maint set per-command time' -ex 'file gdb' -ex quit Reading symbols from gdb... Time for "minsym install worker": wall 0.334, user 0.245, sys 0.011, user+sys 0.256, 76.6 % CPU Time for "minsym install worker": wall 0.336, user 0.242, sys 0.012, user+sys 0.254, 75.6 % CPU Time for "minsym install worker": wall 0.342, user 0.249, sys 0.008, user+sys 0.257, 75.1 % CPU Time for "minsym install worker": wall 0.349, user 0.231, sys 0.015, user+sys 0.246, 70.5 % CPU Time for "minsym install worker": wall 0.352, user 0.231, sys 0.019, user+sys 0.250, 71.0 % CPU Time for "minsym install worker": wall 0.356, user 0.237, sys 0.012, user+sys 0.249, 69.9 % CPU Time for "minsym install worker": wall 0.362, user 0.250, sys 0.009, user+sys 0.259, 71.5 % CPU Time for "minsym install worker": wall 0.362, user 0.240, sys 0.017, user+sys 0.257, 71.0 % CPU warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb line to your configuration file "/home/thiago.bauermann/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/thiago.bauermann/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". Time for "DWARF indexing worker": wall 3.786, user 2.786, sys 0.847, user+sys 3.633, 96.0 % CPU Time for "DWARF indexing worker": wall 3.786, user 2.711, sys 0.954, user+sys 3.665, 96.8 % CPU Time for "DWARF indexing worker": wall 3.786, user 2.741, sys 0.933, user+sys 3.674, 97.0 % CPU Time for "DWARF indexing worker": wall 3.787, user 2.822, sys 0.872, user+sys 3.694, 97.5 % CPU Time for "DWARF indexing worker": wall 3.791, user 2.688, sys 0.979, user+sys 3.667, 96.7 % CPU Time for "DWARF indexing worker": wall 3.791, user 2.771, sys 0.880, user+sys 3.651, 96.3 % CPU Time for "DWARF indexing worker": wall 3.792, user 2.936, sys 0.778, user+sys 3.714, 97.9 % CPU Time for "DWARF indexing worker": wall 3.793, user 2.762, sys 0.905, user+sys 3.667, 96.7 % CPU Time for "DWARF skeletonless type units": wall 0.006, user 0.005, sys 0.000, user+sys 0.005, 83.3 % CPU Time for "DWARF add parent map": wall 0.116, user 0.114, sys 0.001, user+sys 0.115, 99.1 % CPU Time for "DWARF finalize worker": wall 15.504, user 10.265, sys 4.293, user+sys 14.558, 93.9 % CPU Time for "DWARF finalize worker": wall 0.000, user 0.000, sys 0.000, user+sys 0.000, nan % CPU Time for "DWARF finalize worker": wall 15.770, user 10.372, sys 4.360, user+sys 14.732, 93.4 % CPU Time for "DWARF finalize worker": wall 16.329, user 10.965, sys 4.415, user+sys 15.380, 94.2 % CPU Time for "DWARF finalize worker": wall 68.077, user 33.268, sys 26.932, user+sys 60.200, 88.4 % CPU Time for "DWARF finalize worker": wall 70.295, user 34.154, sys 27.911, user+sys 62.065, 88.3 % CPU Time for "DWARF finalize worker": wall 73.817, user 37.446, sys 28.763, user+sys 66.209, 89.7 % CPU Time for "DWARF finalize worker": wall 73.916, user 37.227, sys 28.555, user+sys 65.782, 89.0 % CPU Time for "DWARF finalize worker": wall 74.662, user 37.951, sys 28.837, user+sys 66.788, 89.5 % CPU Tom, sorry for sending you on a wild goose chase. This patch is clearly not needed. -- Thiago (he/him) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values 2026-09-06 20:13 ` Thiago Jung Bauermann @ 2026-09-07 1:02 ` Simon Marchi 2026-09-07 4:21 ` Thiago Jung Bauermann 0 siblings, 1 reply; 6+ messages in thread From: Simon Marchi @ 2026-09-07 1:02 UTC (permalink / raw) To: Thiago Jung Bauermann, Tom de Vries; +Cc: gdb-patches On 2026-09-06 16:13, Thiago Jung Bauermann wrote: > Tom de Vries <tdevries@suse.de> writes: > >> On 9/6/26 6:01 AM, Thiago Jung Bauermann wrote: >>> In the three Linux machines I tested (my x86_64 laptop and two aarch64 >>> servers), gdb.gdb/python-helper.exp has this timeout failure: >>> FAIL: gdb.gdb/python-helper.exp: pretty print type instance flags (timeout) >>> And the slower aarch64 server also has this one: >>> FAIL: gdb.gdb/python-helper.exp: start inner gdb (timeout) >>> Fix these failures by using timeout factors. For the latter, a 2x factor >>> is enough. For the former, I needed 8x. It appears that the "pretty print >>> type instance flags" test is quite demanding. >> >> I tried to see if I could reproduce this. I ended up writing a patch ( >> https://sourceware.org/pipermail/gdb-patches/2026-September/230135.html ) for some timeout >> but I have no idea whether it's the same root cause or not. You may want to test it. >> >> Assuming it's not, LGTM. >> >> Approved-By: Tom de Vries <tdevries@suse.de> > > Thank you! I tested your patch. The same timeouts still happen. > > BUT: > >>> --- >>> I actually noticed these failures because I compared GDB 17.2 test >>> results with GDB 18 ones. OK to also push to the branch? >> >> This makes me wonder if we're dealing with a performance regression here, but yeah, I >> suppose it's ok. > > And from Simon's email: > >> Out of curiosity, is this with GDB build at -O0 or -O2 (or something >> else)? With ASan or other instrumentation? >> >> I am asking because if it's -O2, then it's representative of what a user >> would have in their hands. If some commands take a minute to run, then >> we could at least check if it's because GDB is doing something terribly >> inefficient. > > Your responses made me realise I may be the only one seeing these > timeouts, even if it's accross three machines. I found out that this is > because I compile my test builds with -D_GLIBCXX_DEBUG. I hadn't > realized until now that its impact on GDB performance was so big: > > Without -D_GLIBCXX_DEBUG on the slower aarch64 server: > > $ ./gdb -D data-directory -nx -q -ex 'maint set per-command time' -ex 'file gdb' -ex quit > Reading symbols from gdb... > Time for "minsym install worker": wall 0.237, user 0.135, sys 0.013, user+sys 0.148, 62.4 % CPU > Time for "minsym install worker": wall 0.238, user 0.139, sys 0.003, user+sys 0.142, 59.7 % CPU > Time for "minsym install worker": wall 0.239, user 0.141, sys 0.005, user+sys 0.146, 61.1 % CPU > Time for "minsym install worker": wall 0.248, user 0.148, sys 0.009, user+sys 0.157, 63.3 % CPU > Time for "minsym install worker": wall 0.249, user 0.154, sys 0.003, user+sys 0.157, 63.1 % CPU > Time for "minsym install worker": wall 0.252, user 0.143, sys 0.007, user+sys 0.150, 59.5 % CPU > Time for "minsym install worker": wall 0.256, user 0.151, sys 0.003, user+sys 0.154, 60.2 % CPU > Time for "minsym install worker": wall 0.260, user 0.148, sys 0.004, user+sys 0.152, 58.5 % CPU > ⚠ warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > To enable execution of this file add > add-auto-load-safe-path /home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb > line to your configuration file "/home/thiago.bauermann/.gdbinit". > To completely disable this security protection add > set auto-load safe-path / > line to your configuration file "/home/thiago.bauermann/.gdbinit". > For more information about this security protection see the > "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: > info "(gdb)Auto-loading safe path" > warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > Time for "DWARF indexing worker": wall 0.623, user 0.585, sys 0.035, user+sys 0.620, 99.5 % CPU > Time for "DWARF indexing worker": wall 0.623, user 0.586, sys 0.034, user+sys 0.620, 99.5 % CPU > Time for "DWARF indexing worker": wall 0.623, user 0.597, sys 0.023, user+sys 0.620, 99.5 % CPU > Time for "DWARF indexing worker": wall 0.623, user 0.588, sys 0.033, user+sys 0.621, 99.7 % CPU > Time for "DWARF indexing worker": wall 0.625, user 0.597, sys 0.025, user+sys 0.622, 99.5 % CPU > Time for "DWARF indexing worker": wall 0.625, user 0.576, sys 0.045, user+sys 0.621, 99.4 % CPU > Time for "DWARF indexing worker": wall 0.626, user 0.598, sys 0.025, user+sys 0.623, 99.5 % CPU > Time for "DWARF indexing worker": wall 0.626, user 0.596, sys 0.029, user+sys 0.625, 99.8 % CPU > Time for "DWARF skeletonless type units": wall 0.001, user 0.001, sys 0.000, user+sys 0.001, 100.0 % CPU > Time for "DWARF add parent map": wall 0.089, user 0.087, sys 0.001, user+sys 0.088, 98.9 % CPU > Time for "DWARF finalize worker": wall 2.039, user 2.034, sys 0.002, user+sys 2.036, 99.9 % CPU > Time for "DWARF finalize worker": wall 0.000, user 0.000, sys 0.000, user+sys 0.000, nan % CPU > Time for "DWARF finalize worker": wall 2.045, user 2.040, sys 0.002, user+sys 2.042, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.055, user 2.051, sys 0.001, user+sys 2.052, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.082, user 2.077, sys 0.002, user+sys 2.079, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.087, user 2.082, sys 0.002, user+sys 2.084, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.103, user 2.096, sys 0.004, user+sys 2.100, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.112, user 2.107, sys 0.002, user+sys 2.109, 99.9 % CPU > Time for "DWARF finalize worker": wall 2.114, user 2.110, sys 0.001, user+sys 2.111, 99.9 % CPU > > With -D_GLIBCXX_DEBUG on the slower aarch64 server: > > $ ./gdb -D data-directory -nx -q -ex 'maint set per-command time' -ex 'file gdb' -ex quit > Reading symbols from gdb... > Time for "minsym install worker": wall 0.334, user 0.245, sys 0.011, user+sys 0.256, 76.6 % CPU > Time for "minsym install worker": wall 0.336, user 0.242, sys 0.012, user+sys 0.254, 75.6 % CPU > Time for "minsym install worker": wall 0.342, user 0.249, sys 0.008, user+sys 0.257, 75.1 % CPU > Time for "minsym install worker": wall 0.349, user 0.231, sys 0.015, user+sys 0.246, 70.5 % CPU > Time for "minsym install worker": wall 0.352, user 0.231, sys 0.019, user+sys 0.250, 71.0 % CPU > Time for "minsym install worker": wall 0.356, user 0.237, sys 0.012, user+sys 0.249, 69.9 % CPU > Time for "minsym install worker": wall 0.362, user 0.250, sys 0.009, user+sys 0.259, 71.5 % CPU > Time for "minsym install worker": wall 0.362, user 0.240, sys 0.017, user+sys 0.257, 71.0 % CPU > warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > To enable execution of this file add > add-auto-load-safe-path /home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb > line to your configuration file "/home/thiago.bauermann/.gdbinit". > To completely disable this security protection add > set auto-load safe-path / > line to your configuration file "/home/thiago.bauermann/.gdbinit". > For more information about this security protection see the > "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: > info "(gdb)Auto-loading safe path" > warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > Time for "DWARF indexing worker": wall 3.786, user 2.786, sys 0.847, user+sys 3.633, 96.0 % CPU > Time for "DWARF indexing worker": wall 3.786, user 2.711, sys 0.954, user+sys 3.665, 96.8 % CPU > Time for "DWARF indexing worker": wall 3.786, user 2.741, sys 0.933, user+sys 3.674, 97.0 % CPU > Time for "DWARF indexing worker": wall 3.787, user 2.822, sys 0.872, user+sys 3.694, 97.5 % CPU > Time for "DWARF indexing worker": wall 3.791, user 2.688, sys 0.979, user+sys 3.667, 96.7 % CPU > Time for "DWARF indexing worker": wall 3.791, user 2.771, sys 0.880, user+sys 3.651, 96.3 % CPU > Time for "DWARF indexing worker": wall 3.792, user 2.936, sys 0.778, user+sys 3.714, 97.9 % CPU > Time for "DWARF indexing worker": wall 3.793, user 2.762, sys 0.905, user+sys 3.667, 96.7 % CPU > Time for "DWARF skeletonless type units": wall 0.006, user 0.005, sys 0.000, user+sys 0.005, 83.3 % CPU > Time for "DWARF add parent map": wall 0.116, user 0.114, sys 0.001, user+sys 0.115, 99.1 % CPU > Time for "DWARF finalize worker": wall 15.504, user 10.265, sys 4.293, user+sys 14.558, 93.9 % CPU > Time for "DWARF finalize worker": wall 0.000, user 0.000, sys 0.000, user+sys 0.000, nan % CPU > Time for "DWARF finalize worker": wall 15.770, user 10.372, sys 4.360, user+sys 14.732, 93.4 % CPU > Time for "DWARF finalize worker": wall 16.329, user 10.965, sys 4.415, user+sys 15.380, 94.2 % CPU > Time for "DWARF finalize worker": wall 68.077, user 33.268, sys 26.932, user+sys 60.200, 88.4 % CPU > Time for "DWARF finalize worker": wall 70.295, user 34.154, sys 27.911, user+sys 62.065, 88.3 % CPU > Time for "DWARF finalize worker": wall 73.817, user 37.446, sys 28.763, user+sys 66.209, 89.7 % CPU > Time for "DWARF finalize worker": wall 73.916, user 37.227, sys 28.555, user+sys 65.782, 89.0 % CPU > Time for "DWARF finalize worker": wall 74.662, user 37.951, sys 28.837, user+sys 66.788, 89.5 % CPU And is this with or without compiler optimizations? I have the feeling that C++ without optimizations (especially the standard lib) is slow, because you have a ton of layers of functions that would normally get optimized out, but are there in a -O0 build. > Tom, sorry for sending you on a wild goose chase. > > This patch is clearly not needed. If you have a particularly slow build, what you can do is use a local timeout factor when testing: $ echo 'set gdb_test_timeout [expr 5 * $timeout]' >> testsuite/site.exp On the other hand if the same single test often times out in a lot of scenarios or for a lot of people, then it could make sense to increase the timeout for that one in particular. Simon ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values 2026-09-07 1:02 ` Simon Marchi @ 2026-09-07 4:21 ` Thiago Jung Bauermann 0 siblings, 0 replies; 6+ messages in thread From: Thiago Jung Bauermann @ 2026-09-07 4:21 UTC (permalink / raw) To: Simon Marchi; +Cc: Tom de Vries, gdb-patches Simon Marchi <simark@simark.ca> writes: > On 2026-09-06 16:13, Thiago Jung Bauermann wrote: >> And from Simon's email: >> >>> Out of curiosity, is this with GDB build at -O0 or -O2 (or something >>> else)? With ASan or other instrumentation? >>> >>> I am asking because if it's -O2, then it's representative of what a user >>> would have in their hands. If some commands take a minute to run, then >>> we could at least check if it's because GDB is doing something terribly >>> inefficient. >> >> Your responses made me realise I may be the only one seeing these >> timeouts, even if it's accross three machines. I found out that this is >> because I compile my test builds with -D_GLIBCXX_DEBUG. I hadn't >> realized until now that its impact on GDB performance was so big: >> ⋮ >> With -D_GLIBCXX_DEBUG on the slower aarch64 server: >> >> $ ./gdb -D data-directory -nx -q -ex 'maint set per-command time' -ex 'file gdb' -ex quit >> Reading symbols from gdb... >> Time for "minsym install worker": wall 0.334, user 0.245, sys 0.011, user+sys 0.256, 76.6 % CPU >> Time for "minsym install worker": wall 0.336, user 0.242, sys 0.012, user+sys 0.254, 75.6 % CPU >> Time for "minsym install worker": wall 0.342, user 0.249, sys 0.008, user+sys 0.257, 75.1 % CPU >> Time for "minsym install worker": wall 0.349, user 0.231, sys 0.015, user+sys 0.246, 70.5 % CPU >> Time for "minsym install worker": wall 0.352, user 0.231, sys 0.019, user+sys 0.250, 71.0 % CPU >> Time for "minsym install worker": wall 0.356, user 0.237, sys 0.012, user+sys 0.249, 69.9 % CPU >> Time for "minsym install worker": wall 0.362, user 0.250, sys 0.009, user+sys 0.259, 71.5 % CPU >> Time for "minsym install worker": wall 0.362, user 0.240, sys 0.017, user+sys 0.257, 71.0 % CPU >> warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". >> To enable execution of this file add >> add-auto-load-safe-path /home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.gdb >> line to your configuration file "/home/thiago.bauermann/.gdbinit". >> To completely disable this security protection add >> set auto-load safe-path / >> line to your configuration file "/home/thiago.bauermann/.gdbinit". >> For more information about this security protection see the >> "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: >> info "(gdb)Auto-loading safe path" >> warning: File "/home/thiago.bauermann/src/binutils-gdb-wt/gdb/gdb-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". >> Time for "DWARF indexing worker": wall 3.786, user 2.786, sys 0.847, user+sys 3.633, 96.0 % CPU >> Time for "DWARF indexing worker": wall 3.786, user 2.711, sys 0.954, user+sys 3.665, 96.8 % CPU >> Time for "DWARF indexing worker": wall 3.786, user 2.741, sys 0.933, user+sys 3.674, 97.0 % CPU >> Time for "DWARF indexing worker": wall 3.787, user 2.822, sys 0.872, user+sys 3.694, 97.5 % CPU >> Time for "DWARF indexing worker": wall 3.791, user 2.688, sys 0.979, user+sys 3.667, 96.7 % CPU >> Time for "DWARF indexing worker": wall 3.791, user 2.771, sys 0.880, user+sys 3.651, 96.3 % CPU >> Time for "DWARF indexing worker": wall 3.792, user 2.936, sys 0.778, user+sys 3.714, 97.9 % CPU >> Time for "DWARF indexing worker": wall 3.793, user 2.762, sys 0.905, user+sys 3.667, 96.7 % CPU >> Time for "DWARF skeletonless type units": wall 0.006, user 0.005, sys 0.000, user+sys 0.005, 83.3 % CPU >> Time for "DWARF add parent map": wall 0.116, user 0.114, sys 0.001, user+sys 0.115, 99.1 % CPU >> Time for "DWARF finalize worker": wall 15.504, user 10.265, sys 4.293, user+sys 14.558, 93.9 % CPU >> Time for "DWARF finalize worker": wall 0.000, user 0.000, sys 0.000, user+sys 0.000, nan % CPU >> Time for "DWARF finalize worker": wall 15.770, user 10.372, sys 4.360, user+sys 14.732, 93.4 % CPU >> Time for "DWARF finalize worker": wall 16.329, user 10.965, sys 4.415, user+sys 15.380, 94.2 % CPU >> Time for "DWARF finalize worker": wall 68.077, user 33.268, sys 26.932, user+sys 60.200, 88.4 % CPU >> Time for "DWARF finalize worker": wall 70.295, user 34.154, sys 27.911, user+sys 62.065, 88.3 % CPU >> Time for "DWARF finalize worker": wall 73.817, user 37.446, sys 28.763, user+sys 66.209, 89.7 % CPU >> Time for "DWARF finalize worker": wall 73.916, user 37.227, sys 28.555, user+sys 65.782, 89.0 % CPU >> Time for "DWARF finalize worker": wall 74.662, user 37.951, sys 28.837, user+sys 66.788, 89.5 % CPU > > And is this with or without compiler optimizations? I have the feeling > that C++ without optimizations (especially the standard lib) is slow, > because you have a ton of layers of functions that would normally get > optimized out, but are there in a -O0 build. Ah, sorry for ignoring that part of your question. I thought it wasn't relevant anymore given that I was indeed using instrumentation. I also build with -g -O0. Though now looking at the gcc manpage perhaps I should switch to -g -Og. >> Tom, sorry for sending you on a wild goose chase. >> >> This patch is clearly not needed. > > If you have a particularly slow build, what you can do is use a local > timeout factor when testing: > > $ echo 'set gdb_test_timeout [expr 5 * $timeout]' >> testsuite/site.exp Thanks for the tip. I do that when I test on a setup that I expect to be extra slow. I just failed to noticed that that was the case this time. > On the other hand if the same single test often times out in a lot of > scenarios or for a lot of people, then it could make sense to increase > the timeout for that one in particular. There's one test setup which I use sometimes which may or may not qualify for this test. I'll mention it in my reply to Tom's patch¹. -- Thiago (he/him) ¹ https://inbox.sourceware.org/gdb-patches/20260906154838.139837-1-tdevries@suse.de/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values 2026-09-06 4:01 [PATCH] gdb.gdb/python-helper.exp: Increase timeout values Thiago Jung Bauermann 2026-09-06 15:58 ` Tom de Vries @ 2026-09-06 18:52 ` Simon Marchi 1 sibling, 0 replies; 6+ messages in thread From: Simon Marchi @ 2026-09-06 18:52 UTC (permalink / raw) To: Thiago Jung Bauermann, gdb-patches On 2026-09-06 00:01, Thiago Jung Bauermann wrote: > In the three Linux machines I tested (my x86_64 laptop and two aarch64 > servers), gdb.gdb/python-helper.exp has this timeout failure: > > FAIL: gdb.gdb/python-helper.exp: pretty print type instance flags (timeout) > > And the slower aarch64 server also has this one: > > FAIL: gdb.gdb/python-helper.exp: start inner gdb (timeout) > > Fix these failures by using timeout factors. For the latter, a 2x factor > is enough. For the former, I needed 8x. It appears that the "pretty print > type instance flags" test is quite demanding. Out of curiosity, is this with GDB build at -O0 or -O2 (or something else)? With ASan or other instrumentation? I am asking because if it's -O2, then it's representative of what a user would have in their hands. If some commands take a minute to run, then we could at least check if it's because GDB is doing something terribly inefficient. Simon ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-07 4:21 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-09-06 4:01 [PATCH] gdb.gdb/python-helper.exp: Increase timeout values Thiago Jung Bauermann 2026-09-06 15:58 ` Tom de Vries 2026-09-06 20:13 ` Thiago Jung Bauermann 2026-09-07 1:02 ` Simon Marchi 2026-09-07 4:21 ` Thiago Jung Bauermann 2026-09-06 18:52 ` Simon Marchi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox