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

[gentoo_eshoes]

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 was wondering, in this line:
memmove (old_face+newbytes, old_face+oldbytes, strlen (old+oldbytes) + 1);is 
the strlen correct or should it be strlen (old_face+oldbytes) ? ie. old gets 
changed to old_face

in this context:
memmove (old+newbytes, old+oldbytes, strlen (old+oldbytes) + 1);
memmove (old_face+newbytes, old_face+oldbytes, strlen (old+oldbytes) + 1);
in file lib/readline/display.c
It's probably already correct even though I don't understand why(because I 
don't know what all those variables do), but still I wanted to ask just to be 
sure.

I've tested that it works with either variant... but that's likely because that 
'if (oldbytes != newbytes)' isn't entered in my tests. Oh, if I remove the 'if' 
I see that both strlen variants return the same value, so I guess it's correct 
either way. Nevermind then.


>>> You should just have to run `ulimit -c unlimited'.
>>>
>> Thank you for your reply. It was already 'unlimited'. But when firefox 
>> segfaults it works (that is, `coredumpctl -r`  does list it), yet it doesn't 
>> happen for bash and I thought it's because bash is somehow catching it and 
>> handling it internally, 
>>
>
> 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? */
    }
(the attached patch shows exact context)
Is there anything you could do to fix it?
Thanks in advance.

> Chet
> -- 
> ``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/
>

le.patch
Description: Text Data