[PATCH] gdb.gdb/python-helper.exp: Increase timeout values

[PATCH] gdb.gdb/python-helper.exp: Increase timeout values

[Thiago Jung Bauermann]

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

Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values

[Tom de Vries]

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

Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values

[Simon Marchi]

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

Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values

[Thiago Jung Bauermann]

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)

Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values

[Simon Marchi]

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

Re: [PATCH] gdb.gdb/python-helper.exp: Increase timeout values

[Thiago Jung Bauermann]

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/