Christian Brabandt wrote:
> On Di, 01 Feb 2011, Bram Moolenaar wrote:
>
> > Looking through the code I found one situation where it would read
> > uninitialized memory:
> > :set stl=%!'asdf%'
> >
> > However, the valgrind log looks different from what you show. I suspect
> > there is another problem. Or the same problem in another situation.
> > Can you check with patch 7.3.112 if you can still reproduce the valgrind
> > warning?
>
> Yes, and I can still reproduce the crash with this crash.vim file:
>
>
> #v+
> $ mkdir -p /tmp/vim-crash
> $ cd /tmp/vim-crash
> $ touch {1..65}
> $ cat crash.vim
> function! MyTabLine()
> let s = ''
> for i in range(tabpagenr('$'))
> let s .= '%#TabLine#'
> let s .= ' %{MyTabLabel(' . (i + 1) . ')} '
> endfor
> return s
> endfunction
>
> function! MyTabLabel(n)
> return a:n
> endfunction
>
> set tabline=%!MyTabLine()
> $ vim -u crash.vim --noplugin
> $ vim -u crash.vim --noplugin -N -i NONE --cmd ':set tpm=65' -p
> /tmp/vim-crash/*
> Vim: Caught deadly signal SEGV
> Vim: Finished.
> zsh: segmentation fault (core dumped) ./vim -u crash.vim --noplugin -N -i
> NONE
> --cmd ':set tpm=65' -p
> $
> #v-
>
> When running under valgrind I get this result:
>
> ==16470== Parent PID: 14306
> ==16470==
> ==16470== Invalid write of size 1
> ==16470== at 0x8057AAF: build_stl_str_hl (buffer.c:3470)
> ==16470== by 0x816A96B: win_redr_custom (screen.c:6527)
> ==16470== by 0x816F5DF: draw_tabline (screen.c:9709)
> ==16470== by 0x81605F9: update_screen (screen.c:465)
> ==16470== by 0x80E53CE: main_loop (main.c:1161)
> ==16470== by 0x80E5020: main (main.c:961)
> ==16470== Address 0x4 is not stack'd, malloc'd or (recently) free'd
> ==16470==
> ==16470==
> ==16470== HEAP SUMMARY:
> ==16470== in use at exit: 1,531,154 bytes in 5,006 blocks
> ==16470== total heap usage: 11,375 allocs, 6,369 frees, 10,783,506 bytes
> alloc+ated
> ==16470==
> ==16470== LEAK SUMMARY:
> ==16470== definitely lost: 83,800 bytes in 121 blocks
> ==16470== indirectly lost: 1,491 bytes in 70 blocks
> ==16470== possibly lost: 315 bytes in 8 blocks
> ==16470== still reachable: 1,445,548 bytes in 4,807 blocks
> ==16470== suppressed: 0 bytes in 0 blocks
> ==16470== Rerun with --leak-check=full to see details of leaked memory
>
>
> Problem is this line in buffer.c:
> 3466 /*
> 3467 * Handle up to the next '%' or the end.
> 3468 */
> 3469 while (*s != NUL && *s != '%' && p + 1 < out + outlen)
> 3470 *p++ = *s++;
>
> so p runs out of memory.
Weird, the check for "out + outlen" should avoid that. I'll look into
it later. Unless someone else can make a fix.
--
What is the difference between a professional and an amateur?
The ark was built by an amateur; professionals gave us the Titanic.
/// Bram Moolenaar -- [email protected] -- 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 ///
--
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
