On 8/4/07, Peter Cech <[EMAIL PROTECTED]> wrote: > > On Sat, Aug 04, 2007 at 17:29:37 +0200, Dominique Pelle wrote: > > > > Hi, > > > > Valgrind memory checker finds several errors in vim-7.1 (patches 1-50) > > when built with --enable-multibyte: > > > > $ ./configure --enable-multibyte > > $ make CFLAGS="-O0 -g" > > $ cd src/testdir > > $ valgrind ../vim -u unix.vim -U NONE --noplugin -s dotest.in > > test45.in 2> valgrind-test45.txt > > Could you specify/make available the contents of files unix.vim, > dotest.in and test45.in?
These are the test case scripts located in vim7/src/testdir/. > Also platform details can be useful. $ uname -a Linux pel-laptop 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux > Also, is there a crash (e.g. when compiled with optimizations) or > incorrect result? No crash, no apparent incorrect result (though it does not necessarily mean that there is no bug of course). As described, I built with "-O0 -g" to disable optimization (to make error reporting more reliable, avoiding inlines etc). > Without that it's hard to tell whether the accesses to > uninitialized memory actually (can) result in an incorrect behavior. > That's because valgrind operates on rather low level and cannot see > if the uninitialized values really influence the program flow or if a > higher level logic of the program prevents them to spread further. > In short: We need a human to have a look at the code ;-) 100% agreed. I understand that of course, but accessing uninitialized values is generally very suspicious. I will try to debug and see why (not simple at first sight) but anybody with access to valgrind can reproduce it easily. Cheers -- Dominique --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
