vim9script dictionary containing a list crash

[Christian J. Robinson]

I already sent this to bu...@vim.org but I don't know if Bram saw it. I
am wondering if others can reproduce this crash, by sourcing this
file:

vim9script

var s:d: dict<string>
s:d['a'] = ['one', 'foo']
s:d['b'] = ['two', 'bar']
s:d['c'] = ['three', 'baz']


def Crash()
echo s:d['a'][1]
sleep 2
enddef

call Crash()


--
Christian J. Robinson <hep...@gmail.com> -- https://christianrobinson.name/
Detour: The roughest distance between two points.

[Dominique Pellé]

Christian J. Robinson wrote:

> I already sent this to bu...@vim.org but I don't know if Bram saw it. I
> am wondering if others can reproduce this crash, by sourcing this
> file:
>
> vim9script
>
> var s:d: dict<string>
> s:d['a'] = ['one', 'foo']
> s:d['b'] = ['two', 'bar']
> s:d['c'] = ['three', 'baz']
>
>
> def Crash()
> echo s:d['a'][1]
> sleep 2
> enddef
>
> call Crash()

Yes, I can reproduce with the latest vim-8.2.1812 on Linux-x86_64.

$ ./vim --clean -S crash.vim
Vim: Caught deadly signal SEGV
Vim: Finished.

Segmentation fault (core dumped)

$ valgrind --num-callers=50 ./vim --clean -S crash.vim 2> valgrind.log
$ cat valgrind.log
==7218== Memcheck, a memory error detector
==7218== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7218== Using Valgrind-3.17.0.GIT and LibVEX; rerun with -h for copyright info
==7218== Command: ./vim --clean -S crash.vim
==7218==
==7218== Invalid read of size 4
==7218== at 0x191ADD: echo_string_core (eval.c:4669)
==7218== by 0x19821D: echo_string (eval.c:4766)
==7218== by 0x19821D: echo_one (eval.c:5635)
==7218== by 0x338740: call_def_function (vim9execute.c:1088)
==7218== by 0x3205D1: call_user_func (userfunc.c:1350)
==7218== by 0x321C83: call_user_func_check (userfunc.c:1742)
==7218== by 0x322611: call_func (userfunc.c:2200)
==7218== by 0x322C7E: get_func_tv (userfunc.c:691)
==7218== by 0x3263CF: ex_call (userfunc.c:4112)
==7218== by 0x1C420F: do_one_cmd (ex_docmd.c:2538)
==7218== by 0x1C420F: do_cmdline (ex_docmd.c:984)
==7218== by 0x2B3C74: do_source (scriptfile.c:1432)
==7218== by 0x2B4AF2: cmd_source (scriptfile.c:971)
==7218== by 0x2B4AF2: cmd_source (scriptfile.c:951)
==7218== by 0x1C420F: do_one_cmd (ex_docmd.c:2538)
==7218== by 0x1C420F: do_cmdline (ex_docmd.c:984)
==7218== by 0x39B41D: exe_commands (main.c:3051)
==7218== by 0x39B41D: vim_main2 (main.c:763)
==7218== by 0x8772B96: (below main) (libc-start.c:310)
==7218== Address 0x1020e79c is 4 bytes before an unallocated block of
size 2,193,472 in arena "client"
==7218==
==7218== Invalid write of size 4
==7218== at 0x191AEE: echo_string_core (eval.c:4679)
==7218== by 0x19821D: echo_string (eval.c:4766)
==7218== by 0x19821D: echo_one (eval.c:5635)
==7218== by 0x338740: call_def_function (vim9execute.c:1088)
==7218== by 0x3205D1: call_user_func (userfunc.c:1350)
==7218== by 0x321C83: call_user_func_check (userfunc.c:1742)
==7218== by 0x322611: call_func (userfunc.c:2200)
==7218== by 0x322C7E: get_func_tv (userfunc.c:691)
==7218== by 0x3263CF: ex_call (userfunc.c:4112)
==7218== by 0x1C420F: do_one_cmd (ex_docmd.c:2538)
==7218== by 0x1C420F: do_cmdline (ex_docmd.c:984)
==7218== by 0x2B3C74: do_source (scriptfile.c:1432)
==7218== by 0x2B4AF2: cmd_source (scriptfile.c:971)
==7218== by 0x2B4AF2: cmd_source (scriptfile.c:951)
==7218== by 0x1C420F: do_one_cmd (ex_docmd.c:2538)
==7218== by 0x1C420F: do_cmdline (ex_docmd.c:984)
==7218== by 0x39B41D: exe_commands (main.c:3051)
==7218== by 0x39B41D: vim_main2 (main.c:763)
==7218== by 0x8772B96: (below main) (libc-start.c:310)
==7218== Address 0x1020e79c is 4 bytes before an unallocated block of
size 2,193,472 in arena "client"
...snip...

With the address sanitizer, I get a similar stack:

=================================================================
==8365==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200006065c at pc 0x55e610d07e14 bp 0x7fffd5872fe0 sp
0x7fffd5872fd0
READ of size 4 at 0x60200006065c thread T0
#0 0x55e610d07e13 in echo_string_core /home/pel/sb/vim/src/eval.c:4669
#1 0x55e610d08f57 in echo_string /home/pel/sb/vim/src/eval.c:4766
#2 0x55e610d1058d in echo_one /home/pel/sb/vim/src/eval.c:5635
#3 0x55e6115bc522 in call_def_function
/home/pel/sb/vim/src/vim9execute.c:1088
#4 0x55e6115415d3 in call_user_func /home/pel/sb/vim/src/userfunc.c:1350
#5 0x55e6115477e7 in call_user_func_check
/home/pel/sb/vim/src/userfunc.c:1742
#6 0x55e61154a8f3 in call_func /home/pel/sb/vim/src/userfunc.c:2200
#7 0x55e61153a7dc in get_func_tv /home/pel/sb/vim/src/userfunc.c:691
#8 0x55e611560c1d in ex_call /home/pel/sb/vim/src/userfunc.c:4112
#9 0x55e610dc1445 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2538
#10 0x55e610db4ee7 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:984
#11 0x55e6112e2ad2 in do_source /home/pel/sb/vim/src/scriptfile.c:1432
#12 0x55e6112df879 in cmd_source /home/pel/sb/vim/src/scriptfile.c:971
#13 0x55e6112dfa5a in ex_source /home/pel/sb/vim/src/scriptfile.c:997
#14 0x55e610dc1445 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2538
#15 0x55e610db4ee7 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:984
#16 0x55e610db2c1e in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:592
#17 0x55e61180989a in exe_commands /home/pel/sb/vim/src/main.c:3051
#18 0x55e6117fb51f in vim_main2 /home/pel/sb/vim/src/main.c:763
#19 0x55e6117faa11 in main /home/pel/sb/vim/src/main.c:412
#20 0x7fbabd287b96 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#21 0x55e610b4cf19 in _start (/home/pel/sb/vim/src/vim+0x1164f19)

Address 0x60200006065c is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow
/home/pel/sb/vim/src/eval.c:4669 in echo_string_core
Shadow bytes around the buggy address:
0x0c0480004070: fa fa 00 05 fa fa fd fd fa fa fd fa fa fa 04 fa
0x0c0480004080: fa fa 04 fa fa fa fd fa fa fa fd fa fa fa 04 fa
0x0c0480004090: fa fa 04 fa fa fa fd fa fa fa fd fa fa fa fd fd
0x0c04800040a0: fa fa 00 04 fa fa 00 05 fa fa 00 03 fa fa 00 03
0x0c04800040b0: fa fa fd fa fa fa 02 fa fa fa 00 04 fa fa fd fa
=>0x0c04800040c0: fa fa 02 fa fa fa fa fa fa fa fa[fa]fa fa fa fa
0x0c04800040d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c04800040e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c04800040f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480004100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480004110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==8365==ABORTING

[Bram Moolenaar]

Christian J. Robinson wrote:

> I already sent this to bu...@vim.org but I don't know if Bram saw it. I
> am wondering if others can reproduce this crash, by sourcing this
> file:
>
> vim9script
>
> var s:d: dict<string>
> s:d['a'] = ['one', 'foo']
> s:d['b'] = ['two', 'bar']
> s:d['c'] = ['three', 'baz']
>
>
> def Crash()
> echo s:d['a'][1]
> sleep 2
> enddef
>
> call Crash()

Didn't see it yet. Looks like the compiled code depends on the type of
the value to be correct. But there is no type checking for this
assignment. Let's see if we can make that work... Yep.

There might be similar problems, I haven't tried finding them yet.

--
hundred-and-one symptoms of being an internet addict:
47. You are so familiar with the WWW that you find the search engines useless.

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