public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug tui/30056] double free when using reverse-search for a previous command and Ctrl-C Date: Sun, 28 May 2023 08:17:52 +0000 [thread overview] Message-ID: <bug-30056-4717-RsRdBan8Kx@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-30056-4717@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=30056 --- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=85f4cf41a852b5983ca436615a019315f6dc7301 commit 85f4cf41a852b5983ca436615a019315f6dc7301 Author: Tom de Vries <tdevries@suse.de> Date: Sun May 28 10:17:57 2023 +0200 [readline] Fix double free in _rl_scxt_dispose Consider the following scenario. We start gdb in TUI mode: ... $ gdb -q -tui ... and type ^R which gives us the reverse-isearch prompt in the cmd window: ... (reverse-i-search)`': ... and then type "foo", right-arrow-key, and ^C. In TUI mode, gdb uses a custom rl_getc_function tui_getc. When pressing the right-arrow-key, tui_getc: - attempts to scroll the TUI src window, without any effect, and - returns 0. The intention of returning 0 is mentioned here in tui_dispatch_ctrl_char: ... /* We intercepted the control character, so return 0 (which readline will interpret as a no-op). */ return 0; ... However, after this 0 is returned by the rl_read_key () call in _rl_search_getchar, _rl_read_mbstring is called, which incorrectly interprets 0 as the first part of an utf-8 multibyte char, and tries to read the next char. In this state, the ^C takes effect and we run into a double free because _rl_isearch_cleanup is called twice. Both these issues need fixing independently, though after fixing the first we no longer trigger the second. The first issue is caused by the subtle difference between: - a char array containing 0 chars, which is zero-terminated, and - a char array containing 1 char, which is zero. In mbrtowc terms, this is the difference between: ... mbrtowc (&wc, "", 0, &ps); ... which returns -2, and: ... mbrtowc (&wc, "", 1, &ps); ... which returns 0. Note that _rl_read_mbstring calls _rl_get_char_len without passing it an explicit length parameter, and consequently it cannot distinguish between the two, and defaults to the "0 chars" choice. Note that the same problem doesn't exist in _rl_read_mbchar. Fix this by defaulting to the "1 char" choice in _rl_get_char_len: ... - if (_rl_utf8locale && l > 0 && UTF8_SINGLEBYTE(*src)) + if (_rl_utf8locale && l >= 0 && UTF8_SINGLEBYTE(*src)) ... The second problem happens when the call to _rl_search_getchar in _rl_isearch_callback returns. At that point _rl_isearch_cleanup has already been called from the signal handler, but we proceed regardless, using a cxt pointer that has been freed. Fix this by checking for "RL_ISSTATE (RL_STATE_ISEARCH)" after the call to _rl_search_getchar: ... c = _rl_search_getchar (cxt); + if (!RL_ISSTATE (RL_STATE_ISEARCH)) + return 1; ... Tested on x86_64-linux. Approved-By: Chet Ramey <chet.ramey@case.edu> PR tui/30056 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30056 -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2023-05-28 8:18 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-26 17:47 [Bug tui/30056] New: " etesta at undo dot io 2023-01-27 3:04 ` [Bug tui/30056] " sam at gentoo dot org 2023-01-28 20:00 ` ssbssa at sourceware dot org 2023-05-23 8:38 ` vries at gcc dot gnu.org 2023-05-23 9:53 ` vries at gcc dot gnu.org 2023-05-23 10:29 ` vries at gcc dot gnu.org 2023-05-23 11:50 ` vries at gcc dot gnu.org 2023-05-23 15:06 ` vries at gcc dot gnu.org 2023-05-23 16:06 ` vries at gcc dot gnu.org 2023-05-24 14:11 ` vries at gcc dot gnu.org 2023-05-28 8:17 ` cvs-commit at gcc dot gnu.org [this message] 2023-05-28 8:27 ` vries at gcc dot gnu.org
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=bug-30056-4717-RsRdBan8Kx@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /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: linkBe 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; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).