Hi Bram!
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.
regards,
Christian
--
--
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
