Created attachment 604318 [details] emerge --info >lekto@lapek ~ $ vim >Vim: Caught deadly signal ABRT > Vim: Finished. >Aborted It happens every time when I try to run vim builded by gcc-10, after rebuild with gcc-9 vim works fine. [ebuild R ] app-editors/vim-8.2.0114::gentoo USE="X acl nls -cscope -debug -gpm -lua -luajit -minimal -perl -python -racket -ruby (-selinux) -sound -tcl -terminal -vim-pager" PYTHON_SINGLE_TARGET="python3_6 -python3_7 -python3_8" PYTHON_TARGETS="python3_6 -python3_7 -python3_8" 0 KiB
Created attachment 604322 [details] strace vim
Looks like a stack overflow: Program terminated with signal SIGABRT, Aborted. #0 0x00007f43b3ea24a7 in kill () at ../sysdeps/unix/syscall-template.S:78 78 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) bt #0 0x00007f43b3ea24a7 in kill () at ../sysdeps/unix/syscall-template.S:78 #1 0x0000563edb38bdd6 in may_core_dump () at os_unix.c:3369 #2 may_core_dump () at os_unix.c:3364 #3 mch_exit (r=1) at os_unix.c:3335 #4 <signal handler called> #5 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #6 0x00007f43b3e8a55b in __GI_abort () at abort.c:79 #7 0x00007f43b3ee8359 in __libc_message (action=<optimized out>, fmt=fmt@entry=0x7f43b3fffd4c "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181 #8 0x00007f43b3f81545 in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x7f43b3fffcd8 "buffer overflow detected") at fortify_fail.c:28 #9 0x00007f43b3f81581 in __GI___fortify_fail (msg=msg@entry=0x7f43b3fffcd8 "buffer overflow detected") at fortify_fail.c:44 #10 0x00007f43b3f7f720 in __GI___chk_fail () at chk_fail.c:28 #11 0x0000563edb430ad9 in strcpy (__src=0x563edb48b7a3 "0", __dest=0x563edc345bd1 "") at /usr/include/bits/string_fortified.h:90 #12 add_nr_var (nr=<optimized out>, name=0x563edb48b7a3 "0", v=<optimized out>, dp=0x563edc345f68) at userfunc.c:625 #13 call_user_func (selfdict=<optimized out>, lastline=1, firstline=1, rettv=0x7ffde547b5d0, argvars=<optimized out>, argcount=1, fp=0x563edc2fd390) at userfunc.c:858 #14 call_func (funcname=funcname@entry=0x563edc342f10 "\200\375R27_LocalBrowse", len=len@entry=-1, rettv=rettv@entry=0x7ffde547b5d0, argcount_in=argcount_in@entry=1, argvars_in=argvars_in@entry=0x7ffde547b400, funcexe=funcexe@entry=0x7ffde547b600) at userfunc.c:1626 #15 0x0000563edb431c16 in get_func_tv (name=0x563edc342f10 "\200\375R27_LocalBrowse", len=len@entry=-1, rettv=rettv@entry=0x7ffde547b5d0, arg=arg@entry=0x7ffde547b5b8, funcexe=funcexe@entry=0x7ffde547b600) at userfunc.c:498 #16 0x0000563edb4348b2 in ex_call (eap=0x7ffde547b810) at userfunc.c:3165 #17 0x0000563edb2f6edf in do_one_cmd (cookie=0x7ffde547bf40, fgetline=0x563edb286530 <getnextac>, cstack=0x7ffde547b9d0, sourcing=1, cmdlinep=0x7ffde547b770) at ex_docmd.c:2483 #18 do_cmdline (cmdline=cmdline@entry=0x0, fgetline=fgetline@entry=0x563edb286530 <getnextac>, cookie=cookie@entry=0x7ffde547bf40, flags=flags@entry=7) at ex_docmd.c:976 #19 0x0000563edb287786 in apply_autocmds_group (event=EVENT_BUFENTER, fname=0x563edc342e10 "", fname_io=<optimized out>, force=<optimized out>, group=group@entry=-3, buf=0x563edc0afc50, eap=0x0) at autocmd.c:2106 #20 0x0000563edb288814 in apply_autocmds (event=<optimized out>, fname=<optimized out>, fname_io=<optimized out>, force=<optimized out>, buf=<optimized out>) at autocmd.c:1609 #21 0x0000563edb466f68 in vim_main2 () at main.c:738 #22 0x00007f43b3e8bf1b in __libc_start_main (main=0x563edb281120 <main>, argc=1, argv=0x7ffde547c1c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffde547c1b8) at ../csu/libc-start.c:308 #23 0x0000563edb2835ca in _start () at main.c:2115
(In reply to Sergei Trofimovich from comment #2) > Program terminated with signal SIGABRT, Aborted. ... > #7 0x00007f43b3ee8359 in __libc_message (action=<optimized out>, > fmt=fmt@entry=0x7f43b3fffd4c "*** %s ***: %s terminated\n") > at ../sysdeps/posix/libc_fatal.c:181 > #8 0x00007f43b3f81545 in __GI___fortify_fail_abort > (need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x7f43b3fffcd8 > "buffer overflow detected") > at fortify_fail.c:28 > #9 0x00007f43b3f81581 in __GI___fortify_fail (msg=msg@entry=0x7f43b3fffcd8 > "buffer overflow detected") at fortify_fail.c:44 > #10 0x00007f43b3f7f720 in __GI___chk_fail () at chk_fail.c:28 > #11 0x0000563edb430ad9 in strcpy (__src=0x563edb48b7a3 "0", > __dest=0x563edc345bd1 "") at /usr/include/bits/string_fortified.h:90 > #12 add_nr_var (nr=<optimized out>, name=0x563edb48b7a3 "0", v=<optimized > out>, dp=0x563edc345f68) at userfunc.c:625 ... My guess would be that gcc now can better optimise inliner and sees a hack: src/structs.h: char_u di_key[1]; // key (actually longer!) to implement structs of variable length. gcc emits a warning around that code as: """ x86_64-pc-linux-gnu-gcc -c -I. -Iproto -DHAVE_CONFIG_H -march=sandybridge -mtune=sandybridge -maes --param=l1-cache-size=32 --param=l1-cache-line-size=64 --param=l2-cache-size=8192 -O2 -pipe -fdiagnostics-show-option -frecord-gcc-switches -Wall -Wextra -Wstack-protector -g -o objects/userfunc.o userfunc.c In file included from /usr/include/string.h:494, from os_unix.h:465, from vim.h:234, from userfunc.c:14: In function 'strcpy', inlined from 'add_nr_var' at userfunc.c:625:5, inlined from 'call_user_func' at userfunc.c:858:5, inlined from 'call_func' at userfunc.c:1626:7: /usr/include/bits/string_fortified.h:90:10: warning: '__builtin___memcpy_chk' writing 2 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=] 90 | return __builtin___strcpy_chk (__dest, __src, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ """
Created attachment 604612 [details, diff] vim-8.2.0114-flexible-array-hack.patch You may want to use flexible array members: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html --- a/src/structs.h +++ b/src/structs.h @@ -1414,7 +1414,7 @@ struct dictitem_S { typval_T di_tv; // type and value of the variable char_u di_flags; // flags (only used for variable) - char_u di_key[1]; // key (actually longer!) + char_u di_key[]; // key (actually longer!) }; typedef struct dictitem_S dictitem_T; But make sure the rest of code does not rely on sizeof(struct dictitem_S) or it handles zero accordingly.
Had another look at it today. The trigger is 2-diging gcc major version, and not any fancy optimisations gcc does. Normally vim tries to disable _FORTIFY_SOURCE=2 but only for gcc >=3. https://github.com/vim/vim/pull/5580 fixes crash for me.
Also filed https://github.com/vim/vim/issues/5581 for possible longer-term fix.
Upstream patch was included in gentoo's app-editors/vim-8.2.0360. Works for me.
