9.0.0475 segfaults while compiling vim9script

18 views
Skip to first unread message

Marius Gedminas

unread,
Sep 16, 2022, 6:07:12 AM9/16/22
to vim...@googlegroups.com
vim 9.0.0475 segfauls whenever I try to edit a file, including a
nonexistent file (e.g. vim newfile.txt).

gdb shows the segfault happens in the glibc allocator called while compiling a
vim9script function inside dist#script#DetectFiletype:

Thread 1 "vim" received signal SIGSEGV, Segmentation fault.
0x00007ffff62ce47e in __GI___libc_free (mem=0x3200000010) at ./malloc/malloc.c:3368
(gdb) bt
#0 0x00007ffff62ce47e in __GI___libc_free (mem=0x3200000010) at ./malloc/malloc.c:3368
#1 0x00007ffff62cea00 in __GI___libc_realloc (oldmem=0x3200000010, bytes=0) at ./malloc/malloc.c:3412
#2 0x00005555555ebe3e in ga_grow_inner (gap=0x7fffffffaae8, n=1) at alloc.c:755
#3 0x00005555558a677d in push_type_stack2 (cctx=0x7fffffffaa70, type=0x5555559dd280 <t_number>, decl_type=0x5555559dd1e0 <t_any>) at vim9type.c:1313
#4 0x000055555589cc26 in generate_instr_type2 (cctx=0x7fffffffaa70, isn_type=ISN_PUSHNR, type=0x5555559dd280 <t_number>, decl_type=0x5555559dd1e0 <t_any>) at vim9instr.c:81
#5 0x000055555589cc68 in generate_instr_type (cctx=0x7fffffffaa70, isn_type=ISN_PUSHNR, type=0x5555559dd280 <t_number>) at vim9instr.c:96
#6 0x000055555589dc9d in generate_PUSHNR (cctx=0x7fffffffaa70, number=1) at vim9instr.c:648
#7 0x000055555589da67 in generate_tv_PUSH (cctx=0x7fffffffaa70, tv=0x7fffffff99a0) at vim9instr.c:581
#8 0x0000555555894dff in generate_ppconst (cctx=0x7fffffffaa70, ppconst=0x7fffffff99a0) at vim9expr.c:39
#9 0x000055555589ca3c in compile_expr0_ext (arg=0x7fffffff9d28, cctx=0x7fffffffaa70, is_const=0x0) at vim9expr.c:3291
#10 0x000055555589ca8e in compile_expr0 (arg=0x7fffffff9d28, cctx=0x7fffffffaa70) at vim9expr.c:3302
#11 0x0000555555896539 in compile_arguments (arg=0x7fffffffa718, cctx=0x7fffffffaa70, argcount=0x7fffffff9dac, special_fn=CA_NOT_SPECIAL) at vim9expr.c:644
#12 0x0000555555896d78 in compile_call (arg=0x7fffffffa718, varlen=7, cctx=0x7fffffffaa70, ppconst=0x7fffffffa370, argcount_init=0) at vim9expr.c:799
#13 0x000055555589a698 in compile_expr9 (arg=0x7fffffffa718, cctx=0x7fffffffaa70, ppconst=0x7fffffffa370) at vim9expr.c:2367
#14 0x000055555589a92a in compile_expr8 (arg=0x7fffffffa718, cctx=0x7fffffffaa70, ppconst=0x7fffffffa370) at vim9expr.c:2427
#15 0x000055555589aa35 in compile_expr7 (arg=0x7fffffffa718, cctx=0x7fffffffaa70, ppconst=0x7fffffffa370) at vim9expr.c:2461
#16 0x000055555589ad52 in compile_expr6 (arg=0x7fffffffa718, cctx=0x7fffffffaa70, ppconst=0x7fffffffa370) at vim9expr.c:2540
#17 0x000055555589b23b in compile_expr5 (arg=0x7fffffffa718, cctx=0x7fffffffaa70, ppconst=0x7fffffffa370) at vim9expr.c:2648
#18 0x000055555589b714 in compile_expr4 (arg=0x7fffffffa718, cctx=0x7fffffffaa70, ppconst=0x7fffffffa370) at vim9expr.c:2785
#19 0x000055555589c156 in compile_expr3 (arg=0x7fffffffa718, cctx=0x7fffffffaa70, ppconst=0x7fffffffa370) at vim9expr.c:3059
#20 0x000055555589c1c3 in compile_expr2 (arg=0x7fffffffa718, cctx=0x7fffffffaa70, ppconst=0x7fffffffa370) at vim9expr.c:3084
#21 0x000055555589c29d in compile_expr1 (arg=0x7fffffffa718, cctx=0x7fffffffaa70, ppconst=0x7fffffffa370) at vim9expr.c:3125
#22 0x000055555589c9dc in compile_expr0_ext (arg=0x7fffffffa718, cctx=0x7fffffffaa70, is_const=0x7fffffffa6e4) at vim9expr.c:3284
#23 0x000055555587fbff in compile_assignment (arg=0x5555567c49f6 "line1 = getline(1)", eap=0x7fffffffa9b0, cmdidx=CMD_var, cctx=0x7fffffffaa70) at vim9compile.c:2263
#24 0x0000555555882059 in compile_def_function (ufunc=0x5555567b1770, check_return_type=0, compile_type=CT_NONE, outer_cctx=0x0) at vim9compile.c:3195
#25 0x0000555555890e38 in call_def_function (ufunc=0x5555567b1770, argc_arg=0, argv=0x7fffffffb7d0, flags=0, partial=0x0, funccal=0x55555677aad0, rettv=0x7fffffffb980) at vim9execute.c:5383
#26 0x000055555586b6a2 in call_user_func (fp=0x5555567b1770, argcount=0, argvars=0x7fffffffb7d0, rettv=0x7fffffffb980, funcexe=0x7fffffffb990, selfdict=0x0) at userfunc.c:2685
#27 0x000055555586c93b in call_user_func_check (fp=0x5555567b1770, argcount=0, argvars=0x7fffffffb7d0, rettv=0x7fffffffb980, funcexe=0x7fffffffb990, selfdict=0x0) at userfunc.c:3103
#28 0x000055555586d9f5 in call_func (funcname=0x555556774fa0 "dist#script#DetectFiletype", len=-1, rettv=0x7fffffffb980, argcount_in=0, argvars_in=0x7fffffffb7d0, funcexe=0x7fffffffb990) at userfunc.c:3659
...

This smells like memory corruption to me?

valgrind shows

==26992== Memcheck, a memory error detector
==26992== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26992== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==26992== Command: /home/mg/src/vim/src/vim new.txt
==26992== Parent PID: 26932
==26992==
==26992== Invalid free() / delete / delete[] / realloc()
==26992== at 0x484B1CF: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==26992== by 0x484DD6F: realloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==26992== by 0x19FE3D: ga_grow_inner (alloc.c:755)
==26992== by 0x45A77C: push_type_stack2 (vim9type.c:1313)
==26992== by 0x450C25: generate_instr_type2 (vim9instr.c:81)
==26992== by 0x450C67: generate_instr_type (vim9instr.c:96)
==26992== by 0x451C9C: generate_PUSHNR (vim9instr.c:648)
==26992== by 0x451A66: generate_tv_PUSH (vim9instr.c:581)
==26992== by 0x448DFE: generate_ppconst (vim9expr.c:39)
==26992== by 0x450A3B: compile_expr0_ext (vim9expr.c:3291)
==26992== by 0x450A8D: compile_expr0 (vim9expr.c:3302)
==26992== by 0x44A538: compile_arguments (vim9expr.c:644)
==26992== Address 0x3200000010 is not stack'd, malloc'd or (recently) free'd
==26992==
==26992== Invalid read of size 8
==26992== at 0x45317F: check_internal_func_args (vim9instr.c:1422)
==26992== by 0x45327F: generate_BCALL (vim9instr.c:1450)
==26992== by 0x44AF7E: compile_call (vim9expr.c:846)
==26992== by 0x44E697: compile_expr9 (vim9expr.c:2367)
==26992== by 0x44E929: compile_expr8 (vim9expr.c:2427)
==26992== by 0x44EA34: compile_expr7 (vim9expr.c:2461)
==26992== by 0x44ED51: compile_expr6 (vim9expr.c:2540)
==26992== by 0x44F23A: compile_expr5 (vim9expr.c:2648)
==26992== by 0x44F713: compile_expr4 (vim9expr.c:2785)
==26992== by 0x450155: compile_expr3 (vim9expr.c:3059)
==26992== by 0x4501C2: compile_expr2 (vim9expr.c:3084)
==26992== by 0x45029C: compile_expr1 (vim9expr.c:3125)
==26992== Address 0xfffffffffffffff8 is not stack'd, malloc'd or (recently) free'd
==26992==
==26992==
==26992== Process terminating with default action of signal 11 (SIGSEGV)
==26992== at 0x640775B: kill (syscall-template.S:120)
==26992== by 0x314080: may_core_dump (os_unix.c:3519)
==26992== by 0x314020: mch_exit (os_unix.c:3485)
==26992== by 0x4D72D8: getout (main.c:1743)
==26992== by 0x2D3204: preserve_exit (misc1.c:2243)
==26992== by 0x31163E: deathtrap (os_unix.c:1170)
==26992== by 0x640751F: ??? (in /usr/lib/x86_64-linux-gnu/libc.so.6)
==26992== by 0x45317E: check_internal_func_args (vim9instr.c:1422)
==26992== by 0x45327F: generate_BCALL (vim9instr.c:1450)
==26992== by 0x44AF7E: compile_call (vim9expr.c:846)
==26992== by 0x44E697: compile_expr9 (vim9expr.c:2367)
==26992== by 0x44E929: compile_expr8 (vim9expr.c:2427)

Marius Gedminas
--
Quantum materiae materietur marmota monax si marmota monax materiam possit
materiari?
signature.asc

Marius Gedminas

unread,
Sep 16, 2022, 6:09:38 AM9/16/22
to vim...@googlegroups.com
On Fri, Sep 16, 2022 at 01:07:06PM +0300, Marius Gedminas wrote:
> vim 9.0.0475 segfauls whenever I try to edit a file, including a
> nonexistent file (e.g. vim newfile.txt).

git bisect blames

commit b46c083a5ed9e0c4ac5f3aec577946dcbe8c9dc5
Author: Bram Moolenaar <Br...@vim.org>
Date: Thu Sep 15 17:19:37 2022 +0100

patch 9.0.0470: in :def function all closures in loop get the same variables

Problem: In a :def function all closures in a loop get the same variables.
Solution: When in a loop and a closure refers to a variable declared in the
loop, prepare for making a copy of variables for each closure.

Marius Gedminas
--
Hoffstadter's Law states: "It always takes longer than you think, even when you
consider Hoffstadter's Law."
signature.asc

Marius Gedminas

unread,
Sep 16, 2022, 6:17:26 AM9/16/22
to vim...@googlegroups.com
On Fri, Sep 16, 2022 at 01:09:32PM +0300, Marius Gedminas wrote:
> On Fri, Sep 16, 2022 at 01:07:06PM +0300, Marius Gedminas wrote:
> > vim 9.0.0475 segfauls whenever I try to edit a file, including a
> > nonexistent file (e.g. vim newfile.txt).
>
> git bisect blames
>
> commit b46c083a5ed9e0c4ac5f3aec577946dcbe8c9dc5
> Author: Bram Moolenaar <Br...@vim.org>
> Date: Thu Sep 15 17:19:37 2022 +0100
>
> patch 9.0.0470: in :def function all closures in loop get the same variables

The segfault went away when I did a full rebuild after git clean -dfx.

Weird. Perhaps some data structure layout changed and the Makefile
didn't have the correct dependencies to rebuild everything affected?

Marius Gedminas
--
I don't do martial arts, runny aroundy sports and I certainly don't put on
armour and have at other people with a sword, which I think are the activities
that account for most of the injuries. I just get hit in the face with
staircases wielded by tiny, tiny cats and occasionally am set on fire. Normal
stuff.
-- James Nicoll
signature.asc

Bram Moolenaar

unread,
Sep 16, 2022, 7:29:51 AM9/16/22
to vim...@googlegroups.com, Marius Gedminas

Marius Gedminas wrote:

> On Fri, Sep 16, 2022 at 01:09:32PM +0300, Marius Gedminas wrote:
> > On Fri, Sep 16, 2022 at 01:07:06PM +0300, Marius Gedminas wrote:
> > > vim 9.0.0475 segfauls whenever I try to edit a file, including a
> > > nonexistent file (e.g. vim newfile.txt).
> >
> > git bisect blames
> >
> > commit b46c083a5ed9e0c4ac5f3aec577946dcbe8c9dc5
> > Author: Bram Moolenaar <Br...@vim.org>
> > Date: Thu Sep 15 17:19:37 2022 +0100
> >
> > patch 9.0.0470: in :def function all closures in loop get the same variables
>
> The segfault went away when I did a full rebuild after git clean -dfx.
>
> Weird. Perhaps some data structure layout changed and the Makefile
> didn't have the correct dependencies to rebuild everything affected?

I think, based on the stack trace and what changed, that the dependency
of vim9type.c on vim9.h is missing. The dependencies are not 100%
complete to avoid rebuilding everything on the smallest change.
It does mean that a "make clean" may be needed once in a while.

--
From "know your smileys":
:-H Is missing teeth

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

tooth pik

unread,
Sep 16, 2022, 8:51:07 AM9/16/22
to vim...@googlegroups.com
well i downloaded the latest patches, did a 'make clean', and presto, no more seg faults

i know i don't say this enough, but thanks bram


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20220916112942.4203A1C0846%40moolenaar.net.
Reply all
Reply to author
Forward
0 new messages