Loading ...
Sorry, an error occurred while loading the content.

Re: running valgrind with vim

Expand Messages
  • Dominique Pelle
    ... Hi I am currently trying to investigate those valgrind errors but it does not look easy (win_line() has 2000 lines). So far I have not found how to fix
    Message 1 of 4 , Aug 4, 2007
    • 0 Attachment
      On 8/4/07, Ali Akcaagac <aliakc@...> wrote:
      >
      > On Sat, 2007-08-04 at 17:29 +0200, Dominique Pelle wrote:
      > > Valgrind memory checker finds several errors in vim-7.1 (patches 1-50)
      > > when built with --enable-multibyte:
      >
      > Hello,
      >
      > that's pretty nice that you ran valgrind ontop of vim. I bet everyone
      > else could have done so as well. Would you please tell in more detail.
      > Maybe the parts within the code that you believe have "errors" ? More or
      > less prove us the errors.

      Hi

      I am currently trying to investigate those valgrind errors but it does not
      look easy (win_line() has > 2000 lines). So far I have not found how to
      fix them, but people who know this code better might have better luck.

      -- Dominique

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Ali Akcaagac
      ... I know what valgrind is. mfg, Ali Akcaagac --~--~---------~--~----~------------~-------~--~----~ You received this message from the vim_dev maillist. For
      Message 2 of 4 , Aug 5, 2007
      • 0 Attachment
        On Sat, 2007-08-04 at 22:57 -0400, Fuzzy Logic wrote:
        > Valgrind validates that every bit of memory accessed is properly
        > initialized. It runs the program under a virtual CPU. They are errors,
        > but they could be because of optimizations created by the compiler.

        I know what valgrind is.

        mfg,

        Ali Akcaagac


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Bram Moolenaar
        ... Thanks for digging into this. I spotted a few other places where p_extra may point to text that is not NUL terminated and where utfc_ptr2len() may not work
        Message 3 of 4 , Aug 5, 2007
        • 0 Attachment
          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
          >
          > ...
          >
          > > It's a lot of work to check out the warnings, so please make sure there
          > > are no false warnings.
          >
          >
          > I believe I have a patch to fix errors reported by valgrind in test case 45
          > but please review it.
          >
          > Error was:
          >
          > ==14428== Conditional jump or move depends on uninitialised value(s)
          > ==14428== at 0x80FDD10: utfc_ptr2len (mbyte.c:1676)
          > ==14428== by 0x813EB6B: win_line (screen.c:3586)
          > ==14428== by 0x813BBF0: win_update (screen.c:1760)
          > ==14428== by 0x8139FFE: update_screen (screen.c:522)
          > ==14428== by 0x80CD1CF: main_loop (main.c:1088)
          > ==14428== by 0x80CCF72: main (main.c:939)
          > etc.
          >
          > Variable p_extra at screen.c:3586 was initialized by fill_foldcolumn()
          > with 'foldcolumn' spaces (3 spaces in test case 45). 'p_extra' pointer
          > is actually in this case the local 'extra' array. The rest of 'p_extra'
          > buffer is uninitialized. vim_line() then loops on those 3 spaces but
          > accesses the next characters inside utfc_ptr2len() when multi_byte
          > is enabled, hence causing valgrind to complain when displaying
          > the last space.
          >
          > Bug can be simply triggered when doing ":set foldcolumn" and when
          > vim was built 'multi_byte'. The following command is enough to trigger
          > an error with valgrind:
          >
          > $ vim -u NONE -c 'set foldcolumn=4' 2> valgrind.log
          >
          > I attach the patch to fix the problem. It basically adds NUL character
          > at the end of 'foldcolumn' spaces when. This patch actually fixes all errors
          > reported by valgrind in test case 45.
          >
          > Without patch, bahavior of calling utfc_ptr2len() at line screen.c:3586
          > may be undetermined. It's also slower since it may need to call
          > utf_ptr2len() whereas with patch, function utfc_ptr2len() returns
          > immediately at mbyte.c:1676.

          Thanks for digging into this.

          I spotted a few other places where p_extra may point to text that is not
          NUL terminated and where utfc_ptr2len() may not work correctly. That
          won't give an uninitialized read error, but it may still be wrong.

          --
          From "know your smileys":
          =):-) Uncle Sam

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ download, build and distribute -- http://www.A-A-P.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        Your message has been successfully submitted and would be delivered to recipients shortly.