Re: Segfault when unsetting READLINE_LINE inside 'bind -x'

[Eduardo Bustamante]

On Sun, Apr 23, 2017 at 12:56 AM, Jaren Stangret <sirjaren@gmail.com> wrote:
> Hello,
>
> Instead of segfaulting, BASH should ensure READELINE_LINE is unset or set
> and empty.

I am able to reproduce this with the latest devel branch. Here's the
stack trace:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6e827cc in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.3
(gdb) bt
#0  0x00007ffff6e827cc in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.3
#1  0x00005555556c88bb in maybe_make_readline_line (new_line=0x0) at
bashline.c:2548
#2  0x00005555556cec8a in bash_execute_unix_command (count=1, key=13)
at bashline.c:4142
#3  0x000055555574e9f9 in _rl_dispatch_subseq (key=13,
map=0x555555a56c80 <emacs_standard_keymap>, got_subseq=0) at
readline.c:851
#4  0x000055555574e5d4 in _rl_dispatch (key=0, map=0x555555a56c80
<emacs_standard_keymap>) at readline.c:797
#5  0x000055555574de13 in readline_internal_char () at readline.c:629
#6  0x000055555574dea5 in readline_internal_charloop () at readline.c:656
#7  0x000055555574dec9 in readline_internal () at readline.c:670
#8  0x000055555574d57f in readline (prompt=0x602000003630 "bash-4.4$
") at readline.c:374
#9  0x00005555555e2695 in yy_readline_get () at ./parse.y:1451
#10 0x00005555555e286d in yy_readline_get () at ./parse.y:1482
#11 0x00005555555e24f8 in yy_getc () at ./parse.y:1384
#12 0x00005555555e4842 in shell_getc (remove_quoted_newline=1) at ./parse.y:2284
#13 0x00005555555e72d4 in read_token (command=0) at ./parse.y:3133
#14 0x00005555555e5cb1 in yylex () at ./parse.y:2670
#15 0x00005555555daa62 in yyparse () at y.tab.c:1824
#16 0x00005555555d9c33 in parse_command () at eval.c:294
#17 0x00005555555d9e88 in read_command () at eval.c:338
#18 0x00005555555d90c4 in reader_loop () at eval.c:140
#19 0x00005555555d486e in main (argc=3, argv=0x7fffffffe478,
env=0x7fffffffe498) at shell.c:794

(gdb) frame 1
#1  0x00005555556c88bb in maybe_make_readline_line (new_line=0x0) at
bashline.c:2548
2548      if (strcmp (new_line, rl_line_buffer) != 0)
(gdb) frame 2
#2  0x00005555556cec8a in bash_execute_unix_command (count=1, key=13)
at bashline.c:4142
4142      maybe_make_readline_line (v ? value_cell (v) : 0);

I tried the following patch:

dualbus@debian:~/src/gnu/bash$ git diff -- bashline.c
diff --git a/bashline.c b/bashline.c
index 129714aa..7884416a 100644
--- a/bashline.c
+++ b/bashline.c
@@ -2545,7 +2545,7 @@ static void
 maybe_make_readline_line (new_line)
      char *new_line;
 {
-  if (strcmp (new_line, rl_line_buffer) != 0)
+  if (new_line && strcmp (new_line, rl_line_buffer) != 0)
     {
       rl_point = rl_end;

Which gets rid of the null pointer deference, but it seems to leave
the terminal in a bad state, so the patch is not complete and I have
no clue why.