On 4/11/20 12:04 PM, gentoo_esh...@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.
>> 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.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
*** ../bash-20200408/lib/readline/display.c 2020-04-07 14:55:15.000000000
-0400
--- lib/readline/display.c 2020-04-11 11:46:04.000000000 -0400
***************
*** 1758,1763 ****
--- 1758,1766 ----
ne = new + nmax;
nd = newbytes;
nfd = new + nd;
+ ofdf = old_face;
+ nfdf = new_face;
+
goto dumb_update;
}
if (oldbytes != 0 && newbytes != 0)
