Dominique Pellé wrote:
> I'll try with 32-bits Linux later too.
I've tried with Linux 32 bits and there I could finally reproduce the corruption
with vim-7.4.972 using the script below. Somehow, valgrind or asan do not
see any problem. I can also confirm that the bug is fixed when the latest
vim-7.4.976.
" 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
set maxmem=2048
set maxmemtot=5120
e big.tmp
1,20000y
vnew
put
%s/.*/\=strlen(submatch(0)) . "\t" . submatch(0)/
nohlsearch
sort
--
--
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.
