Re: [PATCH] [gdb/testsuite] Fix timeouts in gdb.base/tls-dlobj.exp

[Tom de Vries <tdevries@suse.de>]

On 1/9/26 5:00 AM, Kevin Buettner wrote:
> Hi Tom,
> 
> I'll state at the outset that I don't have any firm objections to the
> things you've done, but there are some things I'd like to understand
> better first.
> 

Hi Kevin,

thanks for the review.

> On Wed,  7 Jan 2026 10:19:42 +0100
> Tom de Vries <tdevries@suse.de> wrote:
> 
>> When running the testsuite on a busy system, occasionally I run into
>> timeouts in test-case gdb.base/tls-dlobj.exp (gdb build with -O0, as
>> usual).
>>
>> When building gdb with Address Sanitizer (and still with -O0), I always
>> run into timeouts, though it may differ where in the test-case.
>>
>> I can address this using with_timeout_factor, and the test-case finishes
>> after a while without timeouts:
>> ...
>> real	2m30.139s
>> user	2m32.834s
>> sys	0m1.777s
>> ...
>>
>> But the preferred way to deal with this is to cut up the long operation in
>> smaller observable steps, each with their own timeout, so I tried out
>> eliminating the use of continue in the test-case, and using next instead.
> 
> This is the key thing that I don't understand.  Why should using 'next'
> be faster than continuing to a breakpoint?

If you're asking about my intention, I didn't use next expecting it to 
be faster, it just happened to be so.

But as you point out, it's good to understand why, so I dug a little deeper.

I attached at the point that gdb is not making progress, and did a 
backtrace:
...
(gdb) bt
#0  0x00007f094611fe94 in __asan::QuickCheckForUnpoisonedRegion 
(beg=135279688646848, size=16)
     at ../../../../libsanitizer/asan/asan_interceptors_memintrinsics.h:33
#1  ___interceptor_memcpy (dst=0x7d194efaf420, src=0x7b0941c980c0, size=16)
     at 
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc:115
#2  0x0000000001377273 in abbrev_table::read (section=0x7ca9431186f8, 
sect_off=34549)
     at /data/vries/gdb/src/gdb/dwarf2/abbrev.c:225
#3  0x000000000153daad in cutu_reader::cutu_reader (this=0x7b0941dd5d30, 
this_cu=...,
     per_objfile=..., abbrev_table=0x0, existing_cu=0x0, skip_partial=true,
     pretend_language=language_minimal, abbrev_cache=0x0) at 
/data/vries/gdb/src/gdb/dwarf2/read.c:3138
#4  0x000000000153498c in dw2_get_file_names (this_cu=0x7b8943068aa0, 
per_objfile=0x7c4943004240)
     at /data/vries/gdb/src/gdb/dwarf2/read.c:1902
#5  0x00000000015360cf in dw_search_file_matcher 
(per_objfile=0x7c4943004240, cus_to_skip=...,
     file_matcher=...) at /data/vries/gdb/src/gdb/dwarf2/read.c:2100
#6  0x000000000158acb5 in cooked_index_functions::search 
(this=0x7b294305bf30,
     objfile=0x7c4943004040, file_matcher=..., lookup_name=0x0, 
symbol_matcher=..., listener=...,
     search_flags=..., domain=..., lang_matcher=...) at 
/data/vries/gdb/src/gdb/dwarf2/read.c:14683
#7  0x000000000222560a in objfile::map_symtabs_matching_filename 
(this=0x7c4943004040,
     name=0x7b6942fec8c0 
"/data/vries/gdb/src/gdb/testsuite/gdb.base/tls-dlobj.c",
     real_path=0x7b7943034560 
"/data/vries/gdb/binutils-gdb.git/gdb/testsuite/gdb.base/tls-dlobj.c",
     callback=...) at /data/vries/gdb/src/gdb/symfile-debug.c:268
#8  0x00000000022761e7 in iterate_over_symtabs (pspace=0x7c1942ff88c0,
     name=0x7b6942fec8c0 
"/data/vries/gdb/src/gdb/testsuite/gdb.base/tls-dlobj.c", callback=...)
     at /data/vries/gdb/src/gdb/symtab.c:649
#9  0x00000000019b731b in collect_symtabs_from_filename (
     file=0x7b6942fec8c0 
"/data/vries/gdb/src/gdb/testsuite/gdb.base/tls-dlobj.c",
     search_pspace=0x7c1942ff88c0) at 
/data/vries/gdb/src/gdb/linespec.c:3633
#10 0x00000000019b74b9 in symtabs_from_filename (
     filename=0x7b6942fec8c0 
"/data/vries/gdb/src/gdb/testsuite/gdb.base/tls-dlobj.c",
     search_pspace=0x7c1942ff88c0) at 
/data/vries/gdb/src/gdb/linespec.c:3649
#11 0x00000000019ae28f in convert_explicit_location_spec_to_linespec 
(self=0x7b0941f54510,
     result=0x7b0941f545a0,
     source_filename=0x7b6942fec8c0 
"/data/vries/gdb/src/gdb/testsuite/gdb.base/tls-dlobj.c",
     function_name=0x0, fname_match_type=symbol_name_match_type::WILD, 
label_name=0x0, line_offset=...)
     at /data/vries/gdb/src/gdb/linespec.c:2342
#12 0x00000000019aeaf7 in convert_explicit_location_spec_to_sals 
(self=0x7b0941f54510,
     result=0x7b0941f545a0, explicit_spec=0x7b8943010aa0) at 
/data/vries/gdb/src/gdb/linespec.c:2403
#13 0x00000000019b2cce in location_spec_to_sals (parser=0x7b0941f544e0, 
locspec=0x7b8943010aa0)
     at /data/vries/gdb/src/gdb/linespec.c:3078
#14 0x00000000019b321d in decode_line_full (locspec=0x7b8943010aa0, 
flags=1,
     search_pspace=0x7c1942ff88c0, default_symtab=0x0, default_line=0, 
canonical=0x7b0941c04f30,
     select_mode=0x4123460 <multiple_symbols_all> "all", filter=0x0)
     at /data/vries/gdb/src/gdb/linespec.c:3124
#15 0x000000000100384f in code_breakpoint::decode_location_spec 
(this=0x7c194338e840,
     locspec=0x7b8943010aa0, search_pspace=0x7c1942ff88c0)
     at /data/vries/gdb/src/gdb/breakpoint.c:12205
#16 0x000000000100a261 in code_breakpoint::location_spec_to_sals 
(this=0x7c194338e840,
     locspec=0x7b8943010aa0, search_pspace=0x7c1942ff88c0, 
found=0x7b0941e81a30)
     at /data/vries/gdb/src/gdb/breakpoint.c:13138
#17 0x000000000100aead in code_breakpoint::re_set_default 
(this=0x7c194338e840,
     filter_pspace=0x7c1942ff88c0) at 
/data/vries/gdb/src/gdb/breakpoint.c:13220
#18 0x000000000100221a in code_breakpoint::re_set (this=0x7c194338e840, 
pspace=0x7c1942ff88c0)
     at /data/vries/gdb/src/gdb/breakpoint.c:12017
#19 0x000000000100b647 in breakpoint_re_set () at 
/data/vries/gdb/src/gdb/breakpoint.c:13275
#20 0x0000000002199911 in solib_add (pattern=0x0, from_tty=0, readsyms=1)
--Type <RET> for more, q to quit, c to continue without paging--
     at /data/vries/gdb/src/gdb/solib.c:999
#21 0x000000000219d534 in handle_solib_event () at 
/data/vries/gdb/src/gdb/solib.c:1399
#22 0x0000000000fd26ce in bpstat_stop_status (aspace=0x7b4942fe6f90, 
bp_addr=140737353957264,
     thread=0x7c794307f800, ws=..., stop_chain=0x0) at 
/data/vries/gdb/src/gdb/breakpoint.c:5962
#23 0x000000000192d293 in handle_signal_stop (ecs=0x7b0941f33ef0)
     at /data/vries/gdb/src/gdb/infrun.c:7131
#24 0x0000000001929d8d in handle_inferior_event (ecs=0x7b0941f33ef0)
     at /data/vries/gdb/src/gdb/infrun.c:6575
#25 0x000000000191e6b8 in fetch_inferior_event () at 
/data/vries/gdb/src/gdb/infrun.c:4714
#26 0x00000000018b9eb0 in inferior_event_handler (event_type=INF_REG_EVENT)
     at /data/vries/gdb/src/gdb/inf-loop.c:42
#27 0x0000000001a1b4bf in handle_target_event (error=0, client_data=0x0)
     at /data/vries/gdb/src/gdb/linux-nat.c:4449
#28 0x0000000003b07ec2 in handle_file_event (file_ptr=0x7b7943012a60, 
ready_mask=1)
     at /data/vries/gdb/src/gdbsupport/event-loop.cc:551
#29 0x0000000003b08cb4 in gdb_wait_for_event (block=0)
     at /data/vries/gdb/src/gdbsupport/event-loop.cc:672
#30 0x0000000003b05e37 in gdb_do_one_event (mstimeout=-1)
     at /data/vries/gdb/src/gdbsupport/event-loop.cc:216
#31 0x0000000001197fe4 in interp::do_one_event (this=0x7b4942fee550, 
mstimeout=-1)
     at /data/vries/gdb/src/gdb/interps.h:93
#32 0x00000000023a833c in wait_sync_command_done () at 
/data/vries/gdb/src/gdb/top.c:418
#33 0x00000000023a84e4 in maybe_wait_sync_command_done (was_sync=0)
     at /data/vries/gdb/src/gdb/top.c:435
#34 0x00000000023a927d in execute_command (p=0x7b0941c0e458 "", from_tty=0)
     at /data/vries/gdb/src/gdb/top.c:565
#35 0x00000000016893b9 in command_handler (command=0x7b0941c0e450 
"continue")
     at /data/vries/gdb/src/gdb/event-top.c:611
#36 0x00000000023a7b0c in read_command_file (stream=0x7c5943011900)
     at /data/vries/gdb/src/gdb/top.c:333
#37 0x00000000011b0659 in script_from_file (stream=0x7c5943011900,
     file=0x7ffc256f7d6b "outputs/gdb.base/tls-dlobj/gdb.in.1")
     at /data/vries/gdb/src/gdb/cli/cli-script.c:1703
#38 0x000000000115579b in source_script_from_stream (stream=0x7c5943011900,
     file=0x7ffc256f7d6b "outputs/gdb.base/tls-dlobj/gdb.in.1",
     file_to_open=0x7b4942fee7d0 "outputs/gdb.base/tls-dlobj/gdb.in.1")
     at /data/vries/gdb/src/gdb/cli/cli-cmds.c:706
#39 0x0000000001155a4d in source_script_with_search (
     file=0x7ffc256f7d6b "outputs/gdb.base/tls-dlobj/gdb.in.1", 
from_tty=0, search_path=0)
     at /data/vries/gdb/src/gdb/cli/cli-cmds.c:751
#40 0x0000000001155ba5 in source_script (file=0x7ffc256f7d6b 
"outputs/gdb.base/tls-dlobj/gdb.in.1",
     from_tty=0) at /data/vries/gdb/src/gdb/cli/cli-cmds.c:760
#41 0x0000000001b03bf1 in catch_command_errors (command=0x1155b71 
<source_script(char const*, int)>,
     arg=0x7ffc256f7d6b "outputs/gdb.base/tls-dlobj/gdb.in.1", 
from_tty=0, do_bp_actions=false)
     at /data/vries/gdb/src/gdb/main.c:510
#42 0x0000000001b041ea in execute_cmdargs (cmdarg_vec=0x7b0942003a50, 
file_type=CMDARG_FILE,
     cmd_type=CMDARG_COMMAND, ret=0x7b0942003830) at 
/data/vries/gdb/src/gdb/main.c:606
#43 0x0000000001b07864 in captured_main_1 (context=0x7b0941c97da0)
     at /data/vries/gdb/src/gdb/main.c:1348
#44 0x0000000001b07fa3 in captured_main (context=0x7b0941c97da0)
     at /data/vries/gdb/src/gdb/main.c:1371
#45 0x0000000001b080d5 in gdb_main (args=0x7b0941c97da0) at 
/data/vries/gdb/src/gdb/main.c:1400
#46 0x0000000000c3ab13 in main (argc=13, argv=0x7ffc256f6158) at 
/data/vries/gdb/src/gdb/gdb.c:38
...

I issued finish until I found that finishing took noticeable time, which 
was the case for breakpoint_re_set.

I then tried the following experiment: I made all main breakpoints in 
the test-case temporary, which brought total time down from ~2m30s to ~30s.

I then noticed that the debuginfo being read is for glibc, so I did 
"sudo zypper remove glibc-debuginfo" and tried again, which brought 
total time down from ~2m30s to ~3s.

So I guess the answer is that re-inserting breakpoints in presence of 
glibc debug info is slow, and that having less breakpoints to re-insert 
(by making them temporary, or by using next) speeds up the test-case.

So, why is this so slow?

After debugging, I came up with the following patch:
...
$ git diff
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 2e222766579..1e652b8e70e 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -1900,7 +1900,9 @@ dw2_get_file_names (dwarf2_per_cu *this_cu, 
dwarf2_per_objfile *per_objfi
le)
    cutu_reader reader (*this_cu, *per_objfile, nullptr,
  		      per_objfile->get_cu (this_cu), true, language_minimal,
  		      nullptr);
-  if (!reader.is_dummy ())
+  if (reader.is_dummy ())
+    this_cu->files_read = true;
+  else
      dw2_get_file_names_reader (reader.cu (), reader.top_level_die ());

    return this_cu->file_names;
...
which makes sure we don't try to read dummy CUs over and over again.

Using this patch, I get to ~15s, and then making the breakpoints 
temporary I get to ~7s.

So I will resubmit a v2 patch that uses the temporary breakpoint approach.

But I will also file a PR for the dw2_get_file_names issue.

Thanks again for asking that question :)

- Tom