[vim/vim] vim deadly abrt (Issue #16213)
Shane-XB-Qian
Steps to reproduce
one of patch from today caused that:
e29c8bafa (tag: v9.1.0923, origin/master, origin/HEAD, trial, master) patch 9.1.0923: too many strlen() calls in filepath.c
618c4d36c (tag: v9.1.0922) patch 9.1.0923: wrong MIN macro in popupmenu.c
c942f84aa (tag: v9.1.0921) patch 9.1.0921: popupmenu logic is a bit convoluted
95a03fc32 (tag: v9.1.0920) patch 9.1.0920: Vim9: compile_assignment() too long
d66d68763 (tag: v9.1.0919) patch 9.1.0919: filetype: some assembler files are not recognized
5c42c7731 runtime(netrw): do not pollute search history with symlinks
the bt as following:
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff604526e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff60288ff in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff60297b6 in __libc_message_impl (fmt=fmt@entry=0x7ffff61ce8d7 "%s\n") at ../sysdeps/posix/libc_fatal.c:132
#6 0x00007ffff60a8fe5 in malloc_printerr (str=str@entry=0x7ffff61d1c20 "free(): invalid next size (fast)") at ./malloc/malloc.c:5772
#7 0x00007ffff60ab3dc in _int_free (av=0x7ffff6203ac0 <main_arena>, p=<optimized out>, have_lock=0) at ./malloc/malloc.c:4590
#8 0x00007ffff60add9e in __GI___libc_free (mem=0x55555676e4f0) at ./malloc/malloc.c:3398
#9 0x00005555555aef3d in vim_free (x=<optimized out>) at alloc.c:616
#10 0x000055555563bdb8 in free_cmdlines (gap=0x7ffffffe8420) at ex_docmd.c:1549
#11 do_cmdline (cmdline=cmdline@entry=0x0, fgetline=fgetline@entry=0x5555557c9f80 <get_func_line>, cookie=cookie@entry=0x5555567961f0, flags=flags@entry=7) at ex_docmd.c:1153
#12 0x00005555557d2306 in call_user_func
(fp=fp@entry=0x55555630bb00, argcount=argcount@entry=0, argvars=argvars@entry=0x7ffffffe94d0, rettv=<optimized out>, funcexe=<optimized out>, selfdict=selfdict@entry=0x0) at userfunc.c:3202
#13 0x00005555557d2845 in call_user_func_check (selfdict=<optimized out>, funcexe=0x7ffffffe96a0, rettv=0x7ffffffe9cd0, argvars=0x7ffffffe94d0, argcount=0, fp=0x55555630bb00) at userfunc.c:3375
#14 call_user_func_check (fp=0x55555630bb00, argcount=0, argvars=0x7ffffffe94d0, rettv=0x7ffffffe9cd0, funcexe=0x7ffffffe96a0, selfdict=<optimized out>) at userfunc.c:3329
#15 0x00005555557d2f0a in call_func
(funcname=funcname@entry=0x5555565e06b0 "s:getTabline()", len=len@entry=12, rettv=rettv@entry=0x7ffffffe9cd0, argcount_in=argcount_in@entry=0, argvars_in=argvars_in@entry=0x7ffffffe94d0, funcexe=funcexe@entry=0x7ffffffe96a0) at userfunc.c:3999
#16 0x00005555557d349a in get_func_tv
(name=name@entry=0x5555565e06b0 "s:getTabline()", len=12, rettv=rettv@entry=0x7ffffffe9cd0, arg=arg@entry=0x7ffffffe9c80, evalarg=evalarg@entry=0x7ffffffe9ce0, funcexe=0x7ffffffe96a0)
at userfunc.c:2039
#17 0x00005555555ff3af in eval_func
(arg=arg@entry=0x7ffffffe9c80, evalarg=evalarg@entry=0x7ffffffe9ce0, name=name@entry=0x5555565e0b19 "s:getTabline()", name_len=name_len@entry=12, rettv=rettv@entry=0x7ffffffe9cd0, flags=flags@entry=1, basetv=0x0) at eval.c:3021
#18 0x0000555555604607 in eval9_var_func_name (name_start=<synthetic pointer>, evaluate=1, evalarg=0x7ffffffe9ce0, rettv=0x7ffffffe9cd0, arg=0x7ffffffe9c80) at eval.c:4845
not sure how to reproduce, and weird only happened when start vim at home dir, it relied on my vimrc/plugins etc, vim --clean is ok.
Expected behaviour
good to live.
Version of Vim
9.1.0923
Environment
linux
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Can you bisect please? What does s:getTabline() do ? If I would have to guess, I would think it may be related to the filepath.c refactoring, so 9.1.0923, so perhaps try if you can reproduce with v9.1.0922 then
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
you guess correctly, it is.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Alright, I'll back it out
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
@basilisk0315 fyi: I'll revert the change to filepath.c again,
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #16213 as completed via 6cc3027.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
John Marriott
Hi @Shane-XB-Qian,
not sure how to reproduce, and weird only happened when start vim at home dir, it relied on my vimrc/plugins etc, vim --clean is ok.
Could I have a copy of your vimrc/plugins?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
>
> > not sure how to reproduce, and weird only happened when start vim at home dir, it relied on my vimrc/plugins etc, vim --clean is ok.
>
alternatively, i may suggest you just trace the bt and hint: `only happened when start vim at home dir`
--
shane.xb.qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
John Marriott
The backtrace does not reference any code in filepath.c where my changes are.
The issue does not happen at my end, even running vim from my home dir with my config. I am running on arch linux here.
I cannot find any function called getTabline() in vim's distribution and given that the backtrace is talking about user functions I assume that s:getTabline() is custom? If so, can you post it's code here?
When does the failure occur? At startup?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
> The issue does not happen at my end, even running vim from my home dir with my config. I am running on arch linux here.
> I cannot find any function called getTabline() in vim's distribution and given that the backtrace is talking about user functions I assume that s:getTabline() is custom? If so, can you post it's code here?
> When does the failure occur? At startup?
--
shane.xb.qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
John Marriott
Hi @Shane-XB-Qian,
I am testing a theory that the heap is being corrupted and it is manifesting itself when executing the getTabline() function. To that end, could I get you to try the attached for me and report back? Obviously, you will need to remove the ".txt" suffix from the file name.
filepath.c.txt
Thanks
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
i tried it based on #16160, but still deadly abrt,
however i found seems netrw can reproduce it either, perhaps would be easy for you, try ':Lexplore', then close:
// not sure if same, but looks yes:
Vim: Caught deadly signal ABRT
Error detected while processing VimLeave Autocommands for "*"..function <SNR>29_NetrwBookHistSave[7]..<SNR>29_NetrwHome:Vim: Finished.
line 29:
E739: Cannot create directory: /usr/local/share/vim/vimfiles
Error detected while processing VimLeave Autocommands for "*"..function <SNR>29_NetrwBookHistSave:
line 9:
E340: Internal error; if you can reproduce please report a bug
E315: ml_get: Invalid lnum: 1
E340: Internal error; if you can reproduce please report a bug
E315: ml_get: Invalid lnum: 1
line 77:
E340: Internal error; if you can reproduce please report a bug
E315: ml_get: Invalid lnum: 1
E340: Internal error; if you can reproduce please report a bug
E315: ml_get: Invalid lnum: 1
Aborted
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
@basilisk0315
There is a link error when I used HEAD and your patch. (on Linux (Ubuntu 22.04.5 LTS))
/usr/bin/ld: objects/os_unix.o: in function `mch_expandpath':
/home/h_east/path-to-my/vim/src/os_unix.c:6810: multiple definition of `mch_expandpath'; objects/filepath.o:/home/h_east/path-to-my/vim/src/filepath.c:3891: first defined here
collect2: error: ld returned 1 exit status
link.sh: Linking failed
make[1]: *** [Makefile:2061: vim] Error 1
make[1]: Leaving directory '/home/h_east/path-to-my/vim/src'
make: *** [Makefile:29: first] Error 2
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
John Marriott
Hi @Shane-XB-Qian,
Thanks for trying. Out of ideas here.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I suppose we could probably keep the change to unify unix_expandpath() with dos_expandpath() and leave the rest aside for now
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.