Does it happen if you use '-g' rather than '-g3'?
I wonder if this is the gcc and/or linker bug that we've hit before.

(In reply to Tom Tromey from comment #1)
> Does it happen if you use '-g' rather than '-g3'?
> I wonder if this is the gcc and/or linker bug that we've hit before.

Yeah, still hangs for minutes with 100% CPU load.

Worth noting also, you can't make gdb stop whatever it's doing, have to either wait for that to finish or to kill gdb with SIGKILL.

I think this bug is low-priority though because such file is unlikely to come up IRL, only perhaps if as part of autogenerated code…

Reproduced.  Doing a ^C gives us:
...
Breakpoint 1, Solution::numOfSubarrays (this=0x7ffffff9c15f, arr=...) at test.cpp:56
^C
Thread 1 "gdb" received signal SIGINT, Interrupt.
0x00007ffff5a42870 in boost::re_detail_106600::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::find_restart_word() () from /usr/lib64/libsource-highlight.so.4
(gdb) bt
#0  0x00007ffff5a42870 in boost::re_detail_106600::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::find_restart_word() ()
   from /usr/lib64/libsource-highlight.so.4
#1  0x00007ffff5a3ef74 in boost::re_detail_106600::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::find_imp() () from /usr/lib64/libsource-highlight.so.4
#2  0x00007ffff5a87c21 in srchilite::RegexHighlightRule::tryToMatch(__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, srchilite::HighlightToken&, srchilite::MatchingParameters const&) () from /usr/lib64/libsource-highlight.so.4
#3  0x00007ffff5a69781 in srchilite::HighlightState::findBestMatch(__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, srchilite::HighlightToken&, srchilite::MatchingParameters const&) const () from /usr/lib64/libsource-highlight.so.4
#4  0x00007ffff5a6c5b5 in srchilite::SourceHighlighter::highlightParagraph(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib64/libsource-highlight.so.4
#5  0x00007ffff5a6dcc9 in srchilite::SourceFileHighlighter::highlight(std::istream&) ()
   from /usr/lib64/libsource-highlight.so.4
#6  0x00007ffff5a4f52b in srchilite::SourceHighlight::highlight(std::istream&, std::ostream&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib64/libsource-highlight.so.4
#7  0x00000000009d9ab3 in source_cache::ensure (this=this@entry=0x21c8740 <g_source_cache>, s=0x25db0a0)
    at /data/vries/gdb/src/gdb/source-cache.c:254
#8  0x00000000009dab49 in source_cache::get_source_lines (this=0x21c8740 <g_source_cache>, s=s@entry=0x25db0a0, 
    first_line=first_line@entry=56, last_line=last_line@entry=56, lines=lines@entry=0x7fffffffcbb0)
    at /data/vries/gdb/src/gdb/source-cache.c:364
#9  0x00000000009dedbd in print_source_lines_base (s=s@entry=0x25db0a0, line=line@entry=56, 
    stopline=stopline@entry=57, flags=...) at /data/vries/gdb/src/gdb/source.c:1387
#10 0x00000000009df1d5 in print_source_lines (s=s@entry=0x25db0a0, line=line@entry=56, stopline=stopline@entry=57, 
    flags=..., flags@entry=...) at /data/vries/gdb/src/gdb/source.c:1474
#11 0x0000000000a0aa4d in print_frame_info (fp_opts=..., frame=..., print_level=print_level@entry=0, 
    print_what=<optimized out>, print_what@entry=SRC_AND_LOC, print_args=print_args@entry=1, 
    set_current_sal=set_current_sal@entry=1) at /data/vries/gdb/src/gdb/stack.c:1164
#12 0x0000000000a0b048 in print_stack_frame (frame=..., print_level=print_level@entry=0, 
    print_what=print_what@entry=SRC_AND_LOC, set_current_sal=set_current_sal@entry=1)
    at /data/vries/gdb/src/gdb/stack.c:367
#13 0x0000000000740fef in print_stop_location (ws=<synthetic pointer>...) at /data/vries/gdb/src/gdb/infrun.c:8785
#14 print_stop_event (uiout=0x2529d30, displays=<optimized out>) at /data/vries/gdb/src/gdb/infrun.c:8801
#15 0x000000000075c9e3 in interps_notify<bpstat*, int> (method=&virtual interp::on_normal_stop(bpstat*, int))
    at /data/vries/gdb/src/gdb/interps.c:369
#16 interps_notify_normal_stop (bs=bs@entry=0x26ef7f0, print_frame=print_frame@entry=1)
    at /data/vries/gdb/src/gdb/interps.c:402
#17 0x0000000000741a2e in notify_normal_stop (print_frame=1, bs=0x26ef7f0) at /data/vries/gdb/src/gdb/infrun.c:6371
#18 normal_stop () at /data/vries/gdb/src/gdb/infrun.c:9065
#19 0x000000000074f9b1 in fetch_inferior_event () at /data/vries/gdb/src/gdb/infrun.c:4512
#20 0x0000000000fdaf2d in gdb_wait_for_event (block=block@entry=0)
    at /data/vries/gdb/src/gdbsupport/event-loop.cc:694
#21 0x0000000000fdb67f in gdb_do_one_event (mstimeout=mstimeout@entry=-1)
    at /data/vries/gdb/src/gdbsupport/event-loop.cc:217
#22 0x0000000000a6d109 in wait_sync_command_done () at /data/vries/gdb/src/gdb/top.c:427
#23 0x0000000000a70155 in maybe_wait_sync_command_done (was_sync=0) at /data/vries/gdb/src/gdb/top.c:444
#24 execute_command (p=<optimized out>, p@entry=<error reading variable: value has been optimized out>, from_tty=1, 
    from_tty@entry=<error reading variable: value has been optimized out>) at /data/vries/gdb/src/gdb/top.c:577
#25 0x00000000007c7675 in catch_command_errors (command=<optimized out>, arg=<optimized out>, 
    from_tty=<optimized out>, do_bp_actions=do_bp_actions@entry=true) at /data/vries/gdb/src/gdb/main.c:518
#26 0x00000000007c77af in execute_cmdargs (cmdarg_vec=cmdarg_vec@entry=0x7fffffffd810, 
    file_type=file_type@entry=CMDARG_FILE, cmd_type=cmd_type@entry=CMDARG_COMMAND, ret=ret@entry=0x7fffffffd7fc)
    at /data/vries/gdb/src/gdb/main.c:617
#27 0x00000000007c8ee7 in captured_main_1 (context=context@entry=0x7fffffffda00)
    at /data/vries/gdb/src/gdb/main.c:1293
#28 0x00000000007c991b in captured_main (data=data@entry=0x7fffffffda00) at /data/vries/gdb/src/gdb/main.c:1314
#29 gdb_main (args=args@entry=0x7fffffffda20) at /data/vries/gdb/src/gdb/main.c:1343
#30 0x0000000000427fb5 in main (argc=18, argv=0x7fffffffdb48) at /data/vries/gdb/src/gdb/gdb.c:39
(gdb) 
...

Seems to be stuck in srchilite::SourceHighlighter::highlightParagraph.

(In reply to Hi-Angel from comment #0)
> No idea why it's taking so long, given I do not execute any commands that
> would trigger showing these long lines,

This is because source_cache::ensure annotates a file at at time rather than a line at at time.

> but debugging such a file with gdb
> is nigh impossible. 

With "set style sources off" I get:
...
$ time gdb -q a.out -ex "b 56" -ex "set style sources off" -ex run -ex "set confirm off" -ex quit
Reading symbols from a.out...
Breakpoint 1 at 0x400ff5: file test.cpp, line 56.
Starting program: /data/vries/gdb/a.out 

Breakpoint 1, Solution::numOfSubarrays (this=0x7ffffff9c15f, arr=...) at test.cpp:56
56	        return (int) t;

real	0m0.135s
user	0m0.254s
sys	0m0.028s
...

So you can use as workaround:
- "set style sources off", or
- build with --disable-source-highlight and still use source styling with 
  the Python Pygments package, for me that takes about 1 sec.

I was curious, how long does it actually take for me with gdb:
...
$ time gdb -q a.out -ex "b 56" -ex run -ex "set confirm off" -ex quit
Reading symbols from a.out...
Breakpoint 1 at 0x400ff5: file test.cpp, line 56.
Starting program: /data/vries/gdb/a.out 

Breakpoint 1, Solution::numOfSubarrays (this=0x7ffffff9c15f, arr=...) at test.cpp:56
56	        return (int) t;

real	2m17.593s
user	2m16.012s
sys	0m1.728s
...

I guess we're basically looking at:
...
$ time source-highlight test.cpp > /dev/null
Processing test.cpp ... created test.cpp.html

real	2m13.220s
user	2m10.213s
sys	0m3.004s
...
and when using pygments:
...
$ time pygmentize test.cpp > /dev/null

real	0m2.017s
user	0m2.005s
sys	0m0.012s
...

(In reply to Tom de Vries from comment #5)
> So you can use as workaround:
> - build with --disable-source-highlight 

I just found that the same effect can be achieved by "maintenance set gnu-source-highlight enabled off", so there's no need to rebuild.

GNU source highlight is basically unmaintained (I did the last
release and I don't know the source code at all...).
Maybe we should consider dropping it.
Anyway this bug should probably be moved there.

FTR:
...
$ wc test.cpp
    80    229 293884 test.cpp
...

(In reply to Tom Tromey from comment #8)
> GNU source highlight is basically unmaintained (I did the last
> release and I don't know the source code at all...).
> Maybe we should consider dropping it.

If not (yet) dropping it for some reason, at the very least we could reverse the order of preference between pygments and source-highlight.

Possibly also wrap source-highlight (or both) in some timeout stray-jacket.

> Anyway this bug should probably be moved there.

(In reply to Tom Tromey from comment #8)
> Anyway this bug should probably be moved there.

https://savannah.gnu.org/bugs/index.php?64747

(In reply to Tom de Vries from comment #11)
> (In reply to Tom Tromey from comment #8)
> > Anyway this bug should probably be moved there.
> 
> https://savannah.gnu.org/bugs/index.php?64747

I've posted a tentative patch there, with execution time dropping to 3s.

(In reply to Tom de Vries from comment #12)
> (In reply to Tom de Vries from comment #11)
> > (In reply to Tom Tromey from comment #8)
> > > Anyway this bug should probably be moved there.
> > 
> > https://savannah.gnu.org/bugs/index.php?64747
> 
> I've posted a tentative patch there, with execution time dropping to 3s.

Patch submitted here ( https://savannah.gnu.org/patch/?10400 ).

(In reply to Hi-Angel from comment #2)
> Worth noting also, you can't make gdb stop whatever it's doing, have to
> either wait for that to finish or to kill gdb with SIGKILL.

Submitted RFC ( https://sourceware.org/pipermail/gdb-patches/2023-October/203157.html ) to address that.

(In reply to Tom de Vries from comment #14)
> Submitted RFC (
> https://sourceware.org/pipermail/gdb-patches/2023-October/203157.html ) to
> address that.

Re: "RFC: is the warning a good idea, or overkill?"

Yes, I think it is a good idea. A user pressing ^C too quickly has to know they interrupted some ongoing process and lost source highlight.

(sorry for replying here and not on ML but I'm not subscribed. I wish one of these days they'll make a "reply" button on mailing-lists web-ui that would open your email client with a MESSAGE-ID + title 😊)

(In reply to Hi-Angel from comment #15)
> (sorry for replying here and not on ML but I'm not subscribed. I wish one of
> these days they'll make a "reply" button on mailing-lists web-ui that would
> open your email client with a MESSAGE-ID + title 😊)

If you go to https://inbox.sourceware.org/gdb-patches/ , you can click on the thread you're interested in, and then click the reply link on the message you want to reply to, which will take you to the reply instructions.  There are 3 different ways, the 3rd is a mailto link that could work for you.