From: Lancelot SIX <lsix@lancelotsix.com>
To: Tom de Vries <tdevries@suse.de>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v2 4/4] [gdb/cli] Allow source highlighting to be interrupted
Date: Fri, 13 Oct 2023 18:00:50 +0100 [thread overview]
Message-ID: <20231013170026.245lqdb5vg4m4lcp@octopus> (raw)
In-Reply-To: <20231013121953.25917-5-tdevries@suse.de>
Hi Tom,
I have a comment below.
On Fri, Oct 13, 2023 at 02:19:53PM +0200, Tom de Vries wrote:
> In PR cli/30934, a problem is reported where gdb becomes unresponsive for
> 2m13s because the GNU source-highlight library is taking a lot of time to
> annotate the source.
>
> This is due to a problem in the library [1], for which I've posted a
> patch [2], which brings down the annotation time to 3s.
>
> However, GDB should not become unresponsive due to such a problem.
>
> Fix this by installing a srchilite::HighlightEventListener that:
> - checks whether ^C was pressed, and if so
> - asks the user whether it should interrupt highlighting, and if so
> - abandons the highlighting by throwing an exception.
>
> Interrupting the highlighting looks like this to the user:
> ...
> $ gdb -q a.out -ex "b 56"
> Reading symbols from a.out...
> Breakpoint 1 at 0x400e2a: file test.cpp, line 56.
> (gdb) r
> Starting program: /data/vries/gdb/a.out
>
> Breakpoint 1, Solution::numOfSubarrays () at test.cpp:56
> ^CCancel source styling using GNU source highlight of /data/vries/gdb/test.cpp?
> ([y] or n) y
> 56 return (int) t;
> (gdb)
> ...
> Note that line 56 still can be highlighted, just by pygments instead of
> source-highlight.
>
> Tested on x86_64-linux.
>
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30934
>
> [1] https://savannah.gnu.org/bugs/?64747
> [2] https://savannah.gnu.org/patch/index.php?10400
> ---
> gdb/source-cache.c | 62 ++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/source-cache.c b/gdb/source-cache.c
> index f8c98d7e23f..57d9f3b8ab4 100644
> --- a/gdb/source-cache.c
> +++ b/gdb/source-cache.c
> @@ -223,9 +266,21 @@ try_source_highlight (std::string &contents ATTRIBUTE_UNUSED,
> highlighter->setStyleFile ("esc.style");
> }
>
> + gdb_highlight_event_listener event_listener (fullname);
> + highlighter->setHighlightEventListener (&event_listener);
In this instance, highlighter outlives event_listener but keeps a
reference to it. Arguably, the event listener will be reset to point to
another instance before the next invocation of highlight, but I think it
would be cleaner to make sure that the event listener is cleared anyway:
auto clear_event_listener = make_scope_exit ([highlighter]()
{
highlighter->setHighlightEventListener (nullptr);
});
Who knows, maybe one day highlighter's dtor might want to notify
something.
WDYT?
Best,
Lancelot.
> +
> std::istringstream input (contents);
> std::ostringstream output;
> - highlighter->highlight (input, output, lang_name, fullname);
> + {
> + /* We want to be able to interrupt the call to source-highlight. If
> + the current quit_handler is infrun_quit_handler, pressing ^C is
> + ignored by QUIT (assuming target_terminal::is_ours), so install the
> + default quit handler. */
> + scoped_restore restore_quit_handler
> + = make_scoped_restore (&quit_handler, default_quit_handler);
> +
> + highlighter->highlight (input, output, lang_name, fullname);
> + }
> #if __cplusplus >= 202002L
> contents = std::move (output).str();
> #else
> @@ -308,13 +363,16 @@ source_cache::ensure (struct symtab *s)
> reasons:
> - the language is not supported.
> - the language cannot not be auto-detected from the file name.
> + - styling took too long and was interrupted by the user.
> - no stylers available.
>
> Since styling failed, don't try styling the file again after it
> drops from the cache.
>
> Note that clearing the source cache also clears
> - m_no_styling_files. */
> + m_no_styling_files, so if styling took too long, and the user
> + interrupted it, and the source cache gets cleared, the user will
> + need to interrupt styling again. */
> m_no_styling_files.insert (fullname);
> }
> }
> --
> 2.35.3
>
next prev parent reply other threads:[~2023-10-13 17:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 12:19 [PATCH v2 0/4] " Tom de Vries
2023-10-13 12:19 ` [PATCH v2 1/4] [gdb/cli] Skip string copy in source_cache::ensure Tom de Vries
2023-10-13 16:34 ` Lancelot SIX
2023-10-16 7:40 ` Tom de Vries
2023-10-13 12:19 ` [PATCH v2 2/4] [gdb/cli] Factor out try_source_highlight Tom de Vries
2023-10-13 16:52 ` Lancelot SIX
2023-10-16 7:07 ` Tom de Vries
2023-10-16 8:25 ` Lancelot SIX
2023-10-13 12:19 ` [PATCH v2 3/4] [gdb/cli] Keep track of styling failures in source_cache Tom de Vries
2023-10-13 12:19 ` [PATCH v2 4/4] [gdb/cli] Allow source highlighting to be interrupted Tom de Vries
2023-10-13 17:00 ` Lancelot SIX [this message]
2023-10-16 7:47 ` Tom de Vries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231013170026.245lqdb5vg4m4lcp@octopus \
--to=lsix@lancelotsix.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox