Re: bash crashes if TERM is unset and the Delete key is pressed twice

[Emanuele Torre]

On Wed, Dec 14, 2022 at 12:31:39PM -0500, Chet Ramey wrote:
> On 12/13/22 9:00 AM, Emanuele Torre wrote:
> > This happens since 88d69b4fa224d93ef1d26b80229668397bb6496b .
> > 
> > If bash is started with the TERM variable unset or empty, it will
> > segfault and crash if you press the Delete key twice (it only happens
> > for the first prompt, and if you don't press anything before the two
> > Delete key presses).
> 
> I can't reproduce this on macOS, RHEL 7, Fedora 35, or Fedora 37, all
> using xterm.

I can reproduce it consistently on my computer.

I tried to figure out what is causing the issue using gdb on the commit
88d69b4fa224d93ef1d26b80229668397bb6496b .

It seems that, in readline_internal_charloop(), if the memcpy() at line
593 (introduced with that commit) is present:


 #if defined (HAVE_POSIX_SIGSETJMP)
       code = sigsetjmp (_rl_top_level, 0);
 #else
       code = setjmp (_rl_top_level);
 #endif

       if (code)
         {
           (*rl_redisplay_function) ();
           _rl_want_redisplay = 0;
+          memcpy ((void *)_rl_top_level, (void *)olevel, sizeof (procenv_t));

           /* If we longjmped because of a timeout, handle it here. */
           if (RL_ISSTATE (RL_STATE_TIMEOUT))

Then the call to _rl_dispatch() on line 680, causes a segfault:

      lastc = c;
      r = _rl_dispatch ((unsigned char)c, _rl_keymap);

It is called with those `c' and `_rl_keymap' values

  (gdb) p c
  $1 = 27
  (gdb) p _rl_keymap
  $2 = (Keymap) 0x55c653164ae0 <emacs_standard_keymap>

Removing that memcpy() call prevents the segfault.

Between the memcpy() and _rl_dispatch() call, the program enters only in
the following `if' block:

      if (rl_pending_input == 0)
        {
          /* Then initialize the argument and number of keys read. */
          _rl_reset_argument ();
          rl_executing_keyseq[rl_key_sequence_length = 0] = '\0';
        }

I hope this helps.
 emanuele6