Hi
Valgrind detects a bug in Vim-7.4.507 when doing:
$ valgrind vim -c ':setfiletype c' -c 'call feedkeys("i// foo\<CR>\<Esc>")'
=10911== Memcheck, a memory error detector
==10911== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10911== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==10911== Command: ./vim -c :setfiletype\ c -c call\ feedkeys("i//\
foo\\\<CR\>\\\<Esc\>")
==10911==
==10911== Invalid read of size 1
==10911== at 0x4DA9B0: utf_ptr2char (mbyte.c:1705)
==10911== by 0x42EDDE: stop_insert (edit.c:6922)
==10911== by 0x42533A: edit (edit.c:8416)
==10911== by 0x4E7443: nv_edit (normal.c:9080)
==10911== by 0x4E08DE: normal_cmd (normal.c:1160)
==10911== by 0x5DAE42: main_loop (main.c:1342)
==10911== by 0x5DA3F7: main (main.c:1042)
==10911== Address 0xd0786b4 is 1 bytes after a block of size 3 alloc'd
==10911== at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10911== by 0x4D0057: lalloc (misc2.c:921)
==10911== by 0x4C197B: del_bytes (misc1.c:2583)
==10911== by 0x42EDB6: stop_insert (edit.c:6914)
==10911== by 0x42533A: edit (edit.c:8416)
==10911== by 0x4E7443: nv_edit (normal.c:9080)
==10911== by 0x4E08DE: normal_cmd (normal.c:1160)
==10911== by 0x5DAE42: main_loop (main.c:1342)
==10911== by 0x5DA3F7: main (main.c:1042)
Doing a bisection, I see that the bug is introduced by this
recent patch which introduced line edit.c:6922 which is in
the above stack traces:
changeset: 6318:5e998fc610d5
tag: v7-4-492
user: Bram Moolenaar <b...@vim.org>
date: Fri Oct 31 19:20:36 2014 +0100
files: src/edit.c src/testdir/test4.in src/testdir/test4.ok src/version.c
description:
updated for version 7.4.492
Problem: In Insert mode, after inserting a newline that inserts a comment
leader, CTRL-O moves to the right. (ZyX) Issue 57.
Solution: Correct the condition for moving the cursor back to the NUL.
(Christian Brabandt)
ASan (address sanitizer) detects the same bug:
=================================================================
==13507== ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60040007d274 at pc 0x620945 bp 0x7fff3f1c9a40 sp 0x7fff3f1c9a38
READ of size 1 at 0x60040007d274 thread T0
#0 0x620944 in utf_ptr2char /home/dope/sb/vim/src/mbyte.c:1705
#1 0x5ddee5 in gchar_pos /home/dope/sb/vim/src/misc1.c:2683
#2 0x450ed2 in stop_insert /home/dope/sb/vim/src/edit.c:6922
(discriminator 1)
#3 0x45592d in ins_esc /home/dope/sb/vim/src/edit.c:8416
#4 0x43e3ee in edit /home/dope/sb/vim/src/edit.c:988
#5 0x6528f6 in invoke_edit /home/dope/sb/vim/src/normal.c:9080
#6 0x652868 in nv_edit /home/dope/sb/vim/src/normal.c:9053
#7 0x62c92f in normal_cmd /home/dope/sb/vim/src/normal.c:1160
#8 0x843a2f in main_loop /home/dope/sb/vim/src/main.c:1342
#9 0x84301b in main /home/dope/sb/vim/src/main.c:1042
#10 0x7fecd052876c in __libc_start_main ??:?
#11 0x4072e8 in _start ??:?
0x60040007d274 is located 1 bytes to the right of 3-byte region
[0x60040007d270,0x60040007d273)
allocated by thread T0 here:
#0 0x7fecd2a4f56a in malloc ??:?
#1 0x5ff4d8 in lalloc /home/dope/sb/vim/src/misc2.c:921
#2 0x5ff2e2 in alloc /home/dope/sb/vim/src/misc2.c:820
#3 0x5dd859 in del_bytes /home/dope/sb/vim/src/misc1.c:2583
#4 0x5dd303 in del_chars /home/dope/sb/vim/src/misc1.c:2476
#5 0x5dd238 in del_char /home/dope/sb/vim/src/misc1.c:2449
#6 0x450ddd in stop_insert /home/dope/sb/vim/src/edit.c:6914
#7 0x45592d in ins_esc /home/dope/sb/vim/src/edit.c:8416
#8 0x43e3ee in edit /home/dope/sb/vim/src/edit.c:988
#9 0x6528f6 in invoke_edit /home/dope/sb/vim/src/normal.c:9080
#10 0x652868 in nv_edit /home/dope/sb/vim/src/normal.c:9053
#11 0x62c92f in normal_cmd /home/dope/sb/vim/src/normal.c:1160
#12 0x843a2f in main_loop /home/dope/sb/vim/src/main.c:1342
#13 0x84301b in main /home/dope/sb/vim/src/main.c:1042
#14 0x7fecd052876c in __libc_start_main ??:?
Shadow bytes around the buggy address:
0x0c01000079f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0100007a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0100007a10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0100007a20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0100007a30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c0100007a40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa[03]fa
0x0c0100007a50: fa fa 00 03 fa fa fd fa fa fa fd fa fa fa fd fa
0x0c0100007a60: fa fa 01 fa fa fa 00 fa fa fa fd fa fa fa fd fa
0x0c0100007a70: fa fa 02 fa fa fa fd fd fa fa fd fd fa fa fd fd
0x0c0100007a80: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fd
0x0c0100007a90: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fd
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
Heap righ redzone: fb
Freed Heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
==13507== ABORTING
Sorry, no patch as I did not understand Christan's change.
But hopefully the above stack should be enough to figure it out.
Regards
Dominique
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
