Re: [PATCH] Add active mark, face support; activate mark on paste

[Chet Ramey]

On 4/12/20 1:04 AM, gentoo_eshoes@tutanota.com wrote:
> 
> 
> 
> Apr 11, 2020, 23:11 by chet.ramey@case.edu:
> 
>> On 4/11/20 12:04 PM, gentoo_eshoes@tutanota.com wrote:
>>
>>>>
>>>> What's your $PS1?
>>>>
>>> $ echo $PS1
>>> \ -----------\n\ \[\a\]\ \[\e[1;37m\e[42m\]\u@\H\[\e[0m\] \ 
>>> \[\033[1;30m\]$(date "+%Y/%m/%d %H:%M:%S")\[\033[0m\] \ \[\e[0;37m\]\s\V 
>>> t:\l j:\j \ d:${SHLVL} pp:${PPID} p:$$ ut`cat /proc/uptime | cut -f1 
>>> -d.`\[\e[0m\]\n\ \[\e[0;37m\]!\!\[\e[0m\] \ \[\033[0;36m\]\#\[\033[0m\] \ 
>>> $(evalexitcode "${__earlyec[@]}" ) \ \[\e[0m\]$(uname -r) $(uname -v) 
>>> $(ps_lepath "\w")\[ \033];\w\a\] \[\e[1;32m\]\$\[\e[0m\] \
>>>
>>
>> I have to hand it to you; that's one of the most complicated prompt strings
>> I've ever seen.
>>
>> In any event, that didn't help me reproduce the seg fault, but I was able
>> to use the stack traceback you sent to find a problem. I've attached a
>> patch.
>>
> 
> This is amazing, that patch completely fixed the issue, thank you!

I'm glad it worked, but I think this is a more correct version:

*** ../bash-20200408/lib/readline/display.c     2020-04-07 14:55:15.000000000 
-0400
--- lib/readline/display.c      2020-04-12 12:01:22.000000000 -0400
***************
*** 1759,1762 ****
--- 1759,1765 ----
                  nd = newbytes;
                  nfd = new + nd;
+                 ofdf = old_face + oldbytes;
+                 nfdf = new_face + newbytes;
+
                  goto dumb_update;
                }


>> Bash does catch SIGSEGV and does some cleanup, to the extent that it can do
>> anything, and kills itself with the same signal (that's why you see 139 as
>> the exit status). That should still result in a core dump.
>>
> Oh that's good to know. I've tracked down the issue to an exit that happens 
> before bash gets the chance to re-issue the coredump/kill self with SEGV, by 
> using the attached patch to simulate a segmentation fault inside bash, I get 
> this:
> $ ./bash
> TERM='xterm-256color'
> /usr/bin/blugon
> 2069.22 7138.70
> -----------
> user@Z575 2020/04/12 07:00:36 bash5.0.16 t:6 j:0 d:4 pp:16407 p:155787 ut2069
> !76112 1 0  5.6.3-gf9fb85751506 #90 SMP PREEMPT Thu Apr 9 19:22:52 CEST 2020
> /home/user/build/1packages/4used/bash-devel-git/makepkg_pacman/bash/src/bash 
> $ !1!
> !2!
> !3!
> !4!
> 
> that "!4!" is in sig.c here:
>     if (dollar_dollar_pid != 1) {
>       fprintf (stderr, "!4!\n");fflush (stderr);
>       exit (128+sig);   /* just in case the kill fails? */
>     }

That code happens after bash sets the signal handler to SIG_DFL and resends
itself the signal with kill(2), so it's supposed to ensure exit if the kill
fails to kill the bash process.

It avoids the rest of the code in the function, which is supposed to handle
this pathological Linux situation described in this thread:

https://lists.gnu.org/archive/html/bug-bash/2018-04/msg00088.html
https://lists.gnu.org/archive/html/bug-bash/2018-05/msg00001.html

It may be the case that this is called from a signal handler context, where
the terminating signal is blocked. This patch should fix that:

*** ../bash-20200408/sig.c      2020-04-07 16:41:19.000000000 -0400
--- sig.c       2020-04-12 13:26:50.000000000 -0400
***************
*** 609,613 ****
    /* We don't change the set of blocked signals. If a user starts the shell
       with a terminating signal blocked, we won't get here (and if by some
!      magic chance we do, we'll exit below). */
    set_signal_handler (sig, SIG_DFL);

--- 609,617 ----
    /* We don't change the set of blocked signals. If a user starts the shell
       with a terminating signal blocked, we won't get here (and if by some
!      magic chance we do, we'll exit below). What we do is to restore the
!      top-level signal mask, in case this is called from a terminating signal
!      handler context, in which case the signal is blocked. */
!   restore_sigmask ();
!
    set_signal_handler (sig, SIG_DFL);



-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/