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

Re: running valgrind with vim

Expand Messages
  • Ali Akcaagac
    ... 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
    Message 1 of 4 , Aug 4, 2007
      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.

      mfg,

      Ali Akcaagac


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • 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 2 of 4 , Aug 4, 2007
        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 3 of 4 , Aug 5, 2007
          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 4 of 4 , Aug 5, 2007
            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.