[patch] invalid memory access when removing a funcref variable

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[patch] invalid memory access when removing a funcref variable

Lech Lorens
There is a possibility of Vim crashing when a variable or an option
('omnifunc' or 'completefunc') is unset or has its value modified.

The crash is due to an invalid memory access, which is reported by
Valgrind as follows:

#v+
==19657== Invalid write of size 1
==19657==    at 0x8077102: call_func (eval.c:8208)
==19657==    by 0x8076BA9: get_func_tv (eval.c:7976)
==19657==    by 0x8073188: eval7 (eval.c:5023)
==19657==    by 0x8072AA1: eval6 (eval.c:4690)
==19657==    by 0x8072697: eval5 (eval.c:4506)
==19657==    by 0x8071C41: eval4 (eval.c:4201)
==19657==    by 0x8071AAF: eval3 (eval.c:4113)
==19657==    by 0x8071951: eval2 (eval.c:4042)
==19657==    by 0x80717A2: eval1 (eval.c:3967)
==19657==    by 0x8086DD6: ex_echo (eval.c:19459)
==19657==    by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==    by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==    by 0x809CCD4: do_source (ex_cmds2.c:3204)
==19657==    by 0x809C4FF: cmd_source (ex_cmds2.c:2809)
==19657==    by 0x809C457: ex_source (ex_cmds2.c:2782)
==19657==    by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==    by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==    by 0x809E0E3: do_cmdline_cmd (ex_docmd.c:704)
==19657==    by 0x80E2572: exe_commands (main.c:2733)
==19657==    by 0x80DFF26: main (main.c:888)
==19657==  Address 0x4e17343 is 11 bytes inside a block of size 12 free'd
==19657==    at 0x4023836: free (vg_replace_malloc.c:325)
==19657==    by 0x810E0EC: vim_free (misc2.c:1647)
==19657==    by 0x80858FA: clear_tv (eval.c:18562)
==19657==    by 0x80862A8: delete_var (eval.c:19029)
==19657==    by 0x8070E6A: do_unlet (eval.c:3555)
==19657==    by 0x8070CB8: do_unlet_var (eval.c:3499)
==19657==    by 0x8070BC3: ex_unletlock (eval.c:3462)
==19657==    by 0x8070A22: ex_unlet (eval.c:3400)
==19657==    by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==    by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==    by 0x808ABDC: call_user_func (eval.c:21332)
==19657==    by 0x8076F55: call_func (eval.c:8130)
==19657==    by 0x8076BA9: get_func_tv (eval.c:7976)
==19657==    by 0x8073188: eval7 (eval.c:5023)
==19657==    by 0x8072AA1: eval6 (eval.c:4690)
==19657==    by 0x8072697: eval5 (eval.c:4506)
==19657==    by 0x8071C41: eval4 (eval.c:4201)
==19657==    by 0x8071AAF: eval3 (eval.c:4113)
==19657==    by 0x8071951: eval2 (eval.c:4042)
==19657==    by 0x80717A2: eval1 (eval.c:3967)
==19657==    by 0x8086DD6: ex_echo (eval.c:19459)
==19657==    by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==    by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==    by 0x809CCD4: do_source (ex_cmds2.c:3204)
==19657==    by 0x809C4FF: cmd_source (ex_cmds2.c:2809)
==19657==    by 0x809C457: ex_source (ex_cmds2.c:2782)
==19657==    by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==    by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==    by 0x809E0E3: do_cmdline_cmd (ex_docmd.c:704)
==19657==    by 0x80E2572: exe_commands (main.c:2733)
==19657==    by 0x80DFF26: main (main.c:888)
#v-

The invalid memory access can be triggered by executing the following
script:
#v+
func FuncWithRef(a)
  unlet g:FuncRef
  return a:a
endfunc
let g:FuncRef=function("FuncWithRef")
echo g:FuncRef(333)
q
#v-

The attached patch fixes the problem and modifies test 34 to cause the
freed memory.

--
Cheers,
Lech

--
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

funcref-invalid-memory-access.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [patch] invalid memory access when removing a funcref variable

Bram Moolenaar

Lech Lorens wrote:

> There is a possibility of Vim crashing when a variable or an option
> ('omnifunc' or 'completefunc') is unset or has its value modified.
>
> The crash is due to an invalid memory access, which is reported by
> Valgrind as follows:
>
> #v+
> ==19657== Invalid write of size 1
> ==19657==    at 0x8077102: call_func (eval.c:8208)
> ==19657==    by 0x8076BA9: get_func_tv (eval.c:7976)
> ==19657==    by 0x8073188: eval7 (eval.c:5023)
> ==19657==    by 0x8072AA1: eval6 (eval.c:4690)
> ==19657==    by 0x8072697: eval5 (eval.c:4506)
> ==19657==    by 0x8071C41: eval4 (eval.c:4201)
> ==19657==    by 0x8071AAF: eval3 (eval.c:4113)
> ==19657==    by 0x8071951: eval2 (eval.c:4042)
> ==19657==    by 0x80717A2: eval1 (eval.c:3967)
> ==19657==    by 0x8086DD6: ex_echo (eval.c:19459)
> ==19657==    by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
> ==19657==    by 0x809EA29: do_cmdline (ex_docmd.c:1098)
> ==19657==    by 0x809CCD4: do_source (ex_cmds2.c:3204)
> ==19657==    by 0x809C4FF: cmd_source (ex_cmds2.c:2809)
> ==19657==    by 0x809C457: ex_source (ex_cmds2.c:2782)
> ==19657==    by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
> ==19657==    by 0x809EA29: do_cmdline (ex_docmd.c:1098)
> ==19657==    by 0x809E0E3: do_cmdline_cmd (ex_docmd.c:704)
> ==19657==    by 0x80E2572: exe_commands (main.c:2733)
> ==19657==    by 0x80DFF26: main (main.c:888)
> ==19657==  Address 0x4e17343 is 11 bytes inside a block of size 12 free'd
> ==19657==    at 0x4023836: free (vg_replace_malloc.c:325)
> ==19657==    by 0x810E0EC: vim_free (misc2.c:1647)
> ==19657==    by 0x80858FA: clear_tv (eval.c:18562)
> ==19657==    by 0x80862A8: delete_var (eval.c:19029)
> ==19657==    by 0x8070E6A: do_unlet (eval.c:3555)
> ==19657==    by 0x8070CB8: do_unlet_var (eval.c:3499)
> ==19657==    by 0x8070BC3: ex_unletlock (eval.c:3462)
> ==19657==    by 0x8070A22: ex_unlet (eval.c:3400)
> ==19657==    by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
> ==19657==    by 0x809EA29: do_cmdline (ex_docmd.c:1098)
> ==19657==    by 0x808ABDC: call_user_func (eval.c:21332)
> ==19657==    by 0x8076F55: call_func (eval.c:8130)
> ==19657==    by 0x8076BA9: get_func_tv (eval.c:7976)
> ==19657==    by 0x8073188: eval7 (eval.c:5023)
> ==19657==    by 0x8072AA1: eval6 (eval.c:4690)
> ==19657==    by 0x8072697: eval5 (eval.c:4506)
> ==19657==    by 0x8071C41: eval4 (eval.c:4201)
> ==19657==    by 0x8071AAF: eval3 (eval.c:4113)
> ==19657==    by 0x8071951: eval2 (eval.c:4042)
> ==19657==    by 0x80717A2: eval1 (eval.c:3967)
> ==19657==    by 0x8086DD6: ex_echo (eval.c:19459)
> ==19657==    by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
> ==19657==    by 0x809EA29: do_cmdline (ex_docmd.c:1098)
> ==19657==    by 0x809CCD4: do_source (ex_cmds2.c:3204)
> ==19657==    by 0x809C4FF: cmd_source (ex_cmds2.c:2809)
> ==19657==    by 0x809C457: ex_source (ex_cmds2.c:2782)
> ==19657==    by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
> ==19657==    by 0x809EA29: do_cmdline (ex_docmd.c:1098)
> ==19657==    by 0x809E0E3: do_cmdline_cmd (ex_docmd.c:704)
> ==19657==    by 0x80E2572: exe_commands (main.c:2733)
> ==19657==    by 0x80DFF26: main (main.c:888)
> #v-
>
> The invalid memory access can be triggered by executing the following
> script:
> #v+
> func FuncWithRef(a)
>   unlet g:FuncRef
>   return a:a
> endfunc
> let g:FuncRef=function("FuncWithRef")
> echo g:FuncRef(333)
> q
> #v-
>
> The attached patch fixes the problem and modifies test 34 to cause the
> freed memory.

Good catch.  I'll add it to the todo list.

--
From "know your smileys":
 :-| :-|   Deja' vu!

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
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