vim deadly abrt

[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

[chrisbra]

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

[Shane-XB-Qian]

you guess correctly, it is.

[chrisbra]

Alright, I'll back it out

[chrisbra]

@basilisk0315 fyi: I'll revert the change to filepath.c again,

[basilisk0315]

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?

[Shane-XB-Qian]

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?

no, it just some mess of mess, it cannot be ran at your side too; alternatively, i may suggest you just trace the bt and hint: `only happened when start vim at home dir`

…

-- shane.xb.qian

[basilisk0315]

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?

[Shane-XB-Qian]

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?

it is from tabulous plugin, but that nothing special, just get bufname then set it as `tabline` str.

When does the failure occur? At startup?

yes.

…

-- shane.xb.qian

[basilisk0315]

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

[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

[h-east]

@basilisk0315
There is a link error when I used HEAD and your file. (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

[Shane-XB-Qian]

@h-east it defined at #16160

[basilisk0315]

Hi @Shane-XB-Qian,

Thanks for trying. Out of ideas here.