On 16/12/2015 12:45, Mike Williams wrote:
On 16/12/2015 12:22, Mike Williams wrote:
On 16/12/2015 09:27, JohnBeckett wrote:
Dominique Pelle wrote:
Sorry, I forgot to check for plugins. I get no corruption when no plugins are
loaded.
The following shows how to reproduce the corruption from scratch.
In a temp directory, make file auto.vim as follows.
--- Start of auto.vim ---
" Simplified LargeFile.vim
augroup LargeFile
au BufReadPre *
\ let f=expand("<afile>") |
\ if getfsize(f) >= 100*1024*1024 |
\ let b:eikeep= &ei |
\ let b:ulkeep= &ul |
\ set ei=FileType |
\ setlocal noswf bh=unload |
\ let f=escape(substitute(f,'\','/','g'),' ') |
\ exe "au LargeFile BufEnter ".f." set ul=-1" |
\ exe "au LargeFile BufLeave ".f." let &ul=".b:ulkeep."|set ei=".b:eikeep
|
\ exe "au LargeFile BufUnload ".f." au! LargeFile * ". f |
\ echomsg "***note*** handling a large file" |
\ endif
augroup END
--- end ---
Execute the following two lines in Vim to create the big file in the temp
directory:
:let x = [repeat('a',20), repeat('b',25), repeat('c',30), repeat('d',35),
repeat('e',40)]
:call writefile(repeat(x, 1000000), 'big.tmp')
In the temp directory, start Vim with no plugins:
vim -N -u NONE -i NONE
Execute the following commands:
:source auto.vim
:e big.tmp
:1,20000y
:vnew
:put
:%s/.*/\=strlen(submatch(0)) . "\t" . submatch(0)/
:nohlsearch
Sorting the buffer shows obvious corruption (many blank lines and junk):
:sort
John
Hi John
I tried to reproduce the corruption as you described,
but I did not see any problem on Linux x86_64.
I tried with both asan and valgrind. Your bug might
be Win32 specific.
I don't have Windows, but I wonder whether someone
could try Vim with DrMemory. See http://www.drmemory.org/
asan may also work on Windows, but I'm not 100% sure.
See:
http://stackoverflow.com/questions/11806469/clang-with-faddress-sanitizer-on-windows
Using those tools on Windows would obviously be useful
to test Vim beyond this particular sort corruption bug.
Regards
Dominique
Thanks for investigating, and for the good ideas which I'll try to follow. I
skipped the obvious stuff because it seemed unlikely to be an issue with the
platform-specific code.
Here are my results on different systems I could find:
- Vim 7.4.972 win32 on 64-bit Windows 7 (my build): shows bug.
Vim 7.4.972 64bit optimised build on Win7 64-bit: shows bug.
Vim 7.4.972 64bit debug build on Win7 64-bit: no problem.
Looks like it may be a compiler optimizer issue. My compiler on this
machine is VS2012 fully patched. I can check on VS2015 on my home
machine tonight.
Scratch that - got my .exes mixed up. Debug build show bug as well.
Same happens with VS2010 as well FWIW.
hg bisect to the rescue! The sort corruption starts with this commit of
a one line change:
changeset: 4791:65cef998f860
tag: v7.3.1142
user: Bram Moolenaar <[email protected]>
date: Fri Jun 07 19:48:39 2013 +0200
files: src/syntax.c src/version.c
description:
updated for version 7.3.1142
Problem: Memory leak in ":syntime report".
Solution: Clear the grow array. (Dominique Pelle)
- Vim 7.4.827 on Windows XP (from cream): shows bug.
- Vim 7.3.266 on Windows XP (my build): no problem.
- Vim 7.3.415 on 32-bit Linux (my build): no problem.
The "cream" was from installing gvim-7-4-827.exe (Vim-without-Cream):
http://sourceforge.net/projects/cream/files/Vim/
It would be nice if others could report findings.
John
Mike
Mike
Mike
--
They say it is better to give than to receive; I say it depends on the gift.
--
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
