From: Tom de Vries <tdevries@suse.de>
To: chet.ramey@case.edu, bug-readline@gnu.org
Cc: gdb-patches@sourceware.org, Pedro Alves <palves@redhat.com>
Subject: Re: [Bug-readline] heap-buffer-overflow in update_line
Date: Thu, 23 May 2019 07:33:00 -0000 [thread overview]
Message-ID: <e6c37118-a277-d14f-d38b-0a0c06d921eb@suse.de> (raw)
In-Reply-To: <fd2c9f0b-9737-6dad-a444-6e194afa6af9@case.edu>
On 20-05-19 22:14, Chet Ramey wrote:
> On 5/17/19 10:59 AM, Tom de Vries wrote:
>
>> Either way, I'm open for suggestions that make gdb call
>> rl_set_screen_size with legal parameters, and disable features like
>> horizontal scrolling to get unformatted output for the testsuite run.
>
> Here's a patch that will prevent the huge values for the screen width from
> causing at least one issue with line_size:
>
> *** ../readline-8.0-patched/display.c 2018-09-30 21:37:48.000000000 -0400
> --- display.c 2019-05-16 16:50:44.000000000 -0400
> ***************
> *** 604,607 ****
> --- 604,610 ----
> register int n;
>
> + if (line_size <= _rl_screenwidth) /* XXX - for gdb */
> + line_size = _rl_screenwidth + 1;
> +
> if (invisible_line == 0) /* initialize it */
> {
>
> You're still going to have to deal with some horizontal scrolling if the
> input line gets long enough.
>
Hi Chet,
thanks for the patch.
I've tried it out (together with the assert mentioned earlier) and found
that indeed it fixes the assert for the reported scenario:
...
$ TERM=dumb ./gdb -q -ex "set width 0"
(gdb)
...
but I still ran into the assert by typing the command instead of using
"-ex":
...
$ TERM=dumb ./gdb -q
(gdb) set width 0
gdb: display.c:1214: rl_redisplay: Assertion `last_lmargin +
(_rl_screenwidth + visible_wrap_offset) <= line_size' failed.
Aborted (core dumped)
...
Using this additional bit:
...
@@ -528,6 +533,8 @@ rl_redisplay ()
init_line_structures (0);
rl_on_new_line ();
}
+ else if (line_size <= _rl_screenwidth)
+ init_line_structures (_rl_screenwidth + 1);
/* Draw the line into the buffer. */
cpos_buffer_position = -1;
...
I managed to fix the assert also in this scenario, and managed to run
the entire gdb testsuite without triggering the assert.
Is that a good code change?
Thanks,
- Tom
next prev parent reply other threads:[~2019-05-23 7:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <52f237e9-83e8-2a97-4766-e60b867ab914@suse.de>
[not found] ` <d29fbf1f-d33e-77f6-90ed-0eb3779a027c@case.edu>
2019-05-17 14:59 ` Tom de Vries
2019-05-17 15:34 ` Chet Ramey
2019-05-20 20:14 ` Chet Ramey
2019-05-23 7:33 ` Tom de Vries [this message]
2019-05-23 12:38 ` Chet Ramey
2019-05-23 19:28 ` Tom de Vries
2019-05-24 13:08 ` Chet Ramey
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=e6c37118-a277-d14f-d38b-0a0c06d921eb@suse.de \
--to=tdevries@suse.de \
--cc=bug-readline@gnu.org \
--cc=chet.ramey@case.edu \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/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