diff mbox series

gdb, testsuite: increase timeout in gdb.threads/attach-non-stop.exp

Message ID 20260504071636.1571615-4-markus.t.metzger@intel.com
State New
Headers
Series gdb, testsuite: increase timeout in gdb.threads/attach-non-stop.exp |

Commit Message

Metzger, Markus T May 4, 2026, 7:16 a.m. UTC 
  Attaching sporadically timed out on my system while reading symbols...

    Reading symbols from .../attach-non-stop...
    (gdb) gdb_do_cache: can_spawn_for_attach (  )
    builtin_spawn .../attach-non-stop
    attach 729532
    Attaching to program: .../attach-non-stop, process 729532
    [New LWP 729574 (id 2)]
    [New LWP 729573 (id 3)]
    [New LWP 729572 (id 4)]
    [New LWP 729571 (id 5)]
    [New LWP 729570 (id 6)]
    [New LWP 729569 (id 7)]
    [New LWP 729568 (id 8)]
    [New LWP 729567 (id 9)]
    [New LWP 729566 (id 10)]
    [New LWP 729565 (id 11)]
    Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
    FAIL: gdb.threads/attach-non-stop.exp: target-non-stop=off: non-stop=on: cmd=attach: attach (timeout)

Adjust the timeout to avoid sporadic fails.
---
 gdb/testsuite/gdb.threads/attach-non-stop.exp | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

Comments

Simon Marchi May 4, 2026, 3:49 p.m. UTC | #1 
On 5/4/26 3:16 AM, Markus Metzger wrote:
> Attaching sporadically timed out on my system while reading symbols...
> 
>     Reading symbols from .../attach-non-stop...
>     (gdb) gdb_do_cache: can_spawn_for_attach (  )
>     builtin_spawn .../attach-non-stop
>     attach 729532
>     Attaching to program: .../attach-non-stop, process 729532
>     [New LWP 729574 (id 2)]
>     [New LWP 729573 (id 3)]
>     [New LWP 729572 (id 4)]
>     [New LWP 729571 (id 5)]
>     [New LWP 729570 (id 6)]
>     [New LWP 729569 (id 7)]
>     [New LWP 729568 (id 8)]
>     [New LWP 729567 (id 9)]
>     [New LWP 729566 (id 10)]
>     [New LWP 729565 (id 11)]
>     Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
>     FAIL: gdb.threads/attach-non-stop.exp: target-non-stop=off: non-stop=on: cmd=attach: attach (timeout)
> 
> Adjust the timeout to avoid sporadic fails.

Not saying it's necessarily a bad idea, but I'd like some more details
on what is taking so long.  From the above, I understand that GDB is
reading debug info for libc, which is not that big in the grand scheme
of things...

I'd like to know "this step is taking about X seconds", just to make
sure we don't paper over an actual problem.

Simon
Metzger, Markus T May 5, 2026, 6:15 a.m. UTC | #2 
Hello Simon,

>On 5/4/26 3:16 AM, Markus Metzger wrote:
>> Attaching sporadically timed out on my system while reading symbols...
>>
>>     Reading symbols from .../attach-non-stop...
>>     (gdb) gdb_do_cache: can_spawn_for_attach (  )
>>     builtin_spawn .../attach-non-stop
>>     attach 729532
>>     Attaching to program: .../attach-non-stop, process 729532
>>     [New LWP 729574 (id 2)]
>>     [New LWP 729573 (id 3)]
>>     [New LWP 729572 (id 4)]
>>     [New LWP 729571 (id 5)]
>>     [New LWP 729570 (id 6)]
>>     [New LWP 729569 (id 7)]
>>     [New LWP 729568 (id 8)]
>>     [New LWP 729567 (id 9)]
>>     [New LWP 729566 (id 10)]
>>     [New LWP 729565 (id 11)]
>>     Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
>>     FAIL: gdb.threads/attach-non-stop.exp: target-non-stop=off: non-stop=on:
>cmd=attach: attach (timeout)
>>
>> Adjust the timeout to avoid sporadic fails.
>
>Not saying it's necessarily a bad idea, but I'd like some more details
>on what is taking so long.  From the above, I understand that GDB is
>reading debug info for libc, which is not that big in the grand scheme
>of things...
>
>I'd like to know "this step is taking about X seconds", just to make
>sure we don't paper over an actual problem.

The issue happens sporadically, typically while running the entire test
suite (I use FORCE_PARALLEL).  I tried reproducing it by just running this
one test but couldn't.

I cannot say what takes so long and how long exactly it takes, but increasing
the timeout helped the test pass, so it wasn't actually hanging.  One sporadic
fail less.

Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
Simon Marchi May 5, 2026, 3:54 p.m. UTC | #3 
On 2026-05-05 02:15, Metzger, Markus T wrote:
> Hello Simon,
> 
>> On 5/4/26 3:16 AM, Markus Metzger wrote:
>>> Attaching sporadically timed out on my system while reading symbols...
>>>
>>>     Reading symbols from .../attach-non-stop...
>>>     (gdb) gdb_do_cache: can_spawn_for_attach (  )
>>>     builtin_spawn .../attach-non-stop
>>>     attach 729532
>>>     Attaching to program: .../attach-non-stop, process 729532
>>>     [New LWP 729574 (id 2)]
>>>     [New LWP 729573 (id 3)]
>>>     [New LWP 729572 (id 4)]
>>>     [New LWP 729571 (id 5)]
>>>     [New LWP 729570 (id 6)]
>>>     [New LWP 729569 (id 7)]
>>>     [New LWP 729568 (id 8)]
>>>     [New LWP 729567 (id 9)]
>>>     [New LWP 729566 (id 10)]
>>>     [New LWP 729565 (id 11)]
>>>     Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
>>>     FAIL: gdb.threads/attach-non-stop.exp: target-non-stop=off: non-stop=on:
>> cmd=attach: attach (timeout)
>>>
>>> Adjust the timeout to avoid sporadic fails.
>>
>> Not saying it's necessarily a bad idea, but I'd like some more details
>> on what is taking so long.  From the above, I understand that GDB is
>> reading debug info for libc, which is not that big in the grand scheme
>> of things...
>>
>> I'd like to know "this step is taking about X seconds", just to make
>> sure we don't paper over an actual problem.
> 
> The issue happens sporadically, typically while running the entire test
> suite (I use FORCE_PARALLEL).  I tried reproducing it by just running this
> one test but couldn't.
> 
> I cannot say what takes so long and how long exactly it takes, but increasing
> the timeout helped the test pass, so it wasn't actually hanging.  One sporadic
> fail less.

If the timeout is mostly related to how you run the testsuite, then I
think it would be more appropriate to set a local timeout factor.  For
instance, because I build GDB with -O0, with all kinds of checks that
make it slower (_GLIBCXX_DEBUG, ASan), I also get some random timeouts
that are not there when building normally, so I use:

  echo 'set gdb_test_timeout [expr 5 * $timeout]' >> testsuite/site.exp

in my build directory.

Simon
Metzger, Markus T May 6, 2026, 6:33 a.m. UTC | #4 
Hello Simon,

>On 2026-05-05 02:15, Metzger, Markus T wrote:
>> Hello Simon,
>>
>>> On 5/4/26 3:16 AM, Markus Metzger wrote:
>>>> Attaching sporadically timed out on my system while reading symbols...
>>>>
>>>>     Reading symbols from .../attach-non-stop...
>>>>     (gdb) gdb_do_cache: can_spawn_for_attach (  )
>>>>     builtin_spawn .../attach-non-stop
>>>>     attach 729532
>>>>     Attaching to program: .../attach-non-stop, process 729532
>>>>     [New LWP 729574 (id 2)]
>>>>     [New LWP 729573 (id 3)]
>>>>     [New LWP 729572 (id 4)]
>>>>     [New LWP 729571 (id 5)]
>>>>     [New LWP 729570 (id 6)]
>>>>     [New LWP 729569 (id 7)]
>>>>     [New LWP 729568 (id 8)]
>>>>     [New LWP 729567 (id 9)]
>>>>     [New LWP 729566 (id 10)]
>>>>     [New LWP 729565 (id 11)]
>>>>     Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
>>>>     FAIL: gdb.threads/attach-non-stop.exp: target-non-stop=off: non-
>stop=on:
>>> cmd=attach: attach (timeout)
>>>>
>>>> Adjust the timeout to avoid sporadic fails.
>>>
>>> Not saying it's necessarily a bad idea, but I'd like some more details
>>> on what is taking so long.  From the above, I understand that GDB is
>>> reading debug info for libc, which is not that big in the grand scheme
>>> of things...
>>>
>>> I'd like to know "this step is taking about X seconds", just to make
>>> sure we don't paper over an actual problem.
>>
>> The issue happens sporadically, typically while running the entire test
>> suite (I use FORCE_PARALLEL).  I tried reproducing it by just running this
>> one test but couldn't.
>>
>> I cannot say what takes so long and how long exactly it takes, but increasing
>> the timeout helped the test pass, so it wasn't actually hanging.  One sporadic
>> fail less.
>
>If the timeout is mostly related to how you run the testsuite, then I
>think it would be more appropriate to set a local timeout factor.  For
>instance, because I build GDB with -O0, with all kinds of checks that
>make it slower (_GLIBCXX_DEBUG, ASan), I also get some random timeouts
>that are not there when building normally, so I use:
>
>  echo 'set gdb_test_timeout [expr 5 * $timeout]' >> testsuite/site.exp
>
>in my build directory.

Thanks for the hint.  Let me try that instead of this patch.

Markus.

Intel Deutschland GmbH
Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
diff mbox series

Patch

diff --git a/gdb/testsuite/gdb.threads/attach-non-stop.exp b/gdb/testsuite/gdb.threads/attach-non-stop.exp
index 3f55459e7ed..d9ba38e58bf 100644
--- a/gdb/testsuite/gdb.threads/attach-non-stop.exp
+++ b/gdb/testsuite/gdb.threads/attach-non-stop.exp
@@ -48,10 +48,12 @@  proc test {target_non_stop non_stop cmd} {
     set any "\[^\r\n\]*"
 
     if {$cmd == "attach"} {
-	gdb_test_multiple "attach $testpid" $test {
-	    -re "Attaching to program:${any}process $testpid\r\n.*$gdb_prompt " {
-		pass $test
-		set attached 1
+	with_timeout_factor 10 {
+	    gdb_test_multiple "attach $testpid" $test {
+		-re "Attaching to program:${any}process $testpid\r\n.*$gdb_prompt " {
+		    pass $test
+		    set attached 1
+		}
 	    }
 	}