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

(patch) fix access to freed memory in if_getline.c

Expand Messages
  • Dominique Pelle
    Valgrind memory checker detects the following bug in Vim-7.1.280: ==11795== Invalid read of size 1 ==11795== at 0x4023572: strncmp (mc_replace_strmem.c:318)
    Message 1 of 6 , Mar 15, 2008
    • 0 Attachment
      Valgrind memory checker detects the following bug in Vim-7.1.280:

      ==11795== Invalid read of size 1
      ==11795== at 0x4023572: strncmp (mc_replace_strmem.c:318)
      ==11795== by 0x80B6653: getcmdline (ex_getln.c:556)
      ==11795== by 0x80B940B: getexline (ex_getln.c:2100)
      ==11795== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
      ==11795== by 0x8129B52: nv_colon (normal.c:5179)
      ==11795== by 0x812310E: normal_cmd (normal.c:1152)
      ==11795== by 0x80E5F41: main_loop (main.c:1181)
      ==11795== by 0x80E5A91: main (main.c:940)
      ==11795== Address 0x56484AA is 2 bytes inside a block of size 100 free'd
      ==11795== at 0x402237F: free (vg_replace_malloc.c:233)
      ==11795== by 0x8114251: vim_free (misc2.c:1580)
      ==11795== by 0x80B9D01: realloc_cmdbuff (ex_getln.c:2509)
      ==11795== by 0x80BA194: put_on_cmdline (ex_getln.c:2708)
      ==11795== by 0x80B8B8F: getcmdline (ex_getln.c:1679)
      ==11795== by 0x80B940B: getexline (ex_getln.c:2100)
      ==11795== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
      ==11795== by 0x8129B52: nv_colon (normal.c:5179)
      ==11795== by 0x812310E: normal_cmd (normal.c:1152)
      ==11795== by 0x80E5F41: main_loop (main.c:1181)
      ==11795== by 0x80E5A91: main (main.c:940)
      (more errors of this kind follow when it happens)

      Bug is unfortunately difficult to reproduce. I have not found
      a systematic way of reproducing it but I have encountered it a
      couple of times.

      From the above stack traces, it is easy enough to understand though:
      xpc.xp_pattern normally points to somewhere inside ccline.cmdbuff.
      But at line ex_getln.c:556, it points to freed memory according to
      valgrind, because a previous call to put_on_cmdline() has
      reallocated ccline.cmdbuff. Since xpc.xp_pattern was not updated,
      it then points to freed memory.

      Looking at the code, functions that can reallocate ccline.cmdbuff are:

      put_on_cmdline() ...... because it may call realloc_cmdbuff()
      cmdline_paste_str() ... because it may call put_on_cmdline()
      cmdline_paste() ....... because it may call cmdline_paste_str()

      Whenever any of these functions is called, we should take care of
      reinitializing xpc.xp_pattern appropriately.

      Function nextwild() also calls realloc_cmdbuff() but this one
      is OK since it internally reinitializes xpc.xp_pattern.

      I attach a patch which should fix the bug.

      -- Dominique

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Dominique Pelle
      On Sun, Mar 16, 2008 at 12:19 AM, Dominique Pelle ... I saw one additional similar issue even after my previous patch. ==7527== Invalid read of size 1 ==7527==
      Message 2 of 6 , Mar 16, 2008
      • 0 Attachment
        On Sun, Mar 16, 2008 at 12:19 AM, Dominique Pelle
        <dominique.pelle@...> wrote:

        > Valgrind memory checker detects the following bug in Vim-7.1.280:
        >
        > ==11795== Invalid read of size 1
        > ==11795== at 0x4023572: strncmp (mc_replace_strmem.c:318)
        > ==11795== by 0x80B6653: getcmdline (ex_getln.c:556)
        > ==11795== by 0x80B940B: getexline (ex_getln.c:2100)
        > ==11795== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
        > ==11795== by 0x8129B52: nv_colon (normal.c:5179)
        > ==11795== by 0x812310E: normal_cmd (normal.c:1152)
        > ==11795== by 0x80E5F41: main_loop (main.c:1181)
        > ==11795== by 0x80E5A91: main (main.c:940)
        > ==11795== Address 0x56484AA is 2 bytes inside a block of size 100 free'd
        > ==11795== at 0x402237F: free (vg_replace_malloc.c:233)
        > ==11795== by 0x8114251: vim_free (misc2.c:1580)
        > ==11795== by 0x80B9D01: realloc_cmdbuff (ex_getln.c:2509)
        > ==11795== by 0x80BA194: put_on_cmdline (ex_getln.c:2708)
        > ==11795== by 0x80B8B8F: getcmdline (ex_getln.c:1679)
        > ==11795== by 0x80B940B: getexline (ex_getln.c:2100)
        > ==11795== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
        > ==11795== by 0x8129B52: nv_colon (normal.c:5179)
        > ==11795== by 0x812310E: normal_cmd (normal.c:1152)
        > ==11795== by 0x80E5F41: main_loop (main.c:1181)
        > ==11795== by 0x80E5A91: main (main.c:940)
        > (more errors of this kind follow when it happens)
        >
        > Bug is unfortunately difficult to reproduce. I have not found
        > a systematic way of reproducing it but I have encountered it a
        > couple of times.
        >
        > From the above stack traces, it is easy enough to understand though:
        > xpc.xp_pattern normally points to somewhere inside ccline.cmdbuff.
        > But at line ex_getln.c:556, it points to freed memory according to
        > valgrind, because a previous call to put_on_cmdline() has
        > reallocated ccline.cmdbuff. Since xpc.xp_pattern was not updated,
        > it then points to freed memory.
        >
        > Looking at the code, functions that can reallocate ccline.cmdbuff are:
        >
        > put_on_cmdline() ...... because it may call realloc_cmdbuff()
        > cmdline_paste_str() ... because it may call put_on_cmdline()
        > cmdline_paste() ....... because it may call cmdline_paste_str()
        >
        > Whenever any of these functions is called, we should take care of
        > reinitializing xpc.xp_pattern appropriately.
        >
        > Function nextwild() also calls realloc_cmdbuff() but this one
        > is OK since it internally reinitializes xpc.xp_pattern.
        >
        > I attach a patch which should fix the bug.
        >
        > -- Dominique


        I saw one additional similar issue even after my previous patch.

        ==7527== Invalid read of size 1
        ==7527== at 0x4023572: strncmp (mc_replace_strmem.c:318)
        ==7527== by 0x80B6656: getcmdline (ex_getln.c:557)
        ==7527== by 0x80B94FF: getexline (ex_getln.c:2126)
        ==7527== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
        ==7527== by 0x8129C46: nv_colon (normal.c:5179)
        ==7527== by 0x8123202: normal_cmd (normal.c:1152)
        ==7527== by 0x80E6035: main_loop (main.c:1181)
        ==7527== by 0x80E5B85: main (main.c:940)
        ==7527== Address 0x55B1024 is 4 bytes inside a block of size 140 free'd
        ==7527== at 0x402237F: free (vg_replace_malloc.c:233)
        ==7527== by 0x8114345: vim_free (misc2.c:1580)
        ==7527== by 0x80C0061: ex_window (ex_getln.c:6143)
        ==7527== by 0x80B6BF8: getcmdline (ex_getln.c:734)
        ==7527== by 0x80B94FF: getexline (ex_getln.c:2126)
        ==7527== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
        ==7527== by 0x8129C46: nv_colon (normal.c:5179)
        ==7527== by 0x8123202: normal_cmd (normal.c:1152)
        ==7527== by 0x80E6035: main_loop (main.c:1181)
        ==7527== by 0x80E5B85: main (main.c:940)

        Function ex_window() may also free and reallocate ccline.cmdbuff
        hence invalidating xpc.xp_pattern.

        I attach an update of my previous patch which should also fix this issue.

        Cheers
        -- Dominique

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Bram Moolenaar
        ... This is tricky, since xp_pattern is separate from the allocated command line. It s very easy to forget updating xp_pattern. One solution would be to
        Message 3 of 6 , Mar 16, 2008
        • 0 Attachment
          Dominique Pelle wrote:

          > > Valgrind memory checker detects the following bug in Vim-7.1.280:
          > >
          > > ==11795== Invalid read of size 1
          > > ==11795== at 0x4023572: strncmp (mc_replace_strmem.c:318)
          > > ==11795== by 0x80B6653: getcmdline (ex_getln.c:556)
          > > ==11795== by 0x80B940B: getexline (ex_getln.c:2100)
          > > ==11795== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
          > > ==11795== by 0x8129B52: nv_colon (normal.c:5179)
          > > ==11795== by 0x812310E: normal_cmd (normal.c:1152)
          > > ==11795== by 0x80E5F41: main_loop (main.c:1181)
          > > ==11795== by 0x80E5A91: main (main.c:940)
          > > ==11795== Address 0x56484AA is 2 bytes inside a block of size 100 free'd
          > > ==11795== at 0x402237F: free (vg_replace_malloc.c:233)
          > > ==11795== by 0x8114251: vim_free (misc2.c:1580)
          > > ==11795== by 0x80B9D01: realloc_cmdbuff (ex_getln.c:2509)
          > > ==11795== by 0x80BA194: put_on_cmdline (ex_getln.c:2708)
          > > ==11795== by 0x80B8B8F: getcmdline (ex_getln.c:1679)
          > > ==11795== by 0x80B940B: getexline (ex_getln.c:2100)
          > > ==11795== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
          > > ==11795== by 0x8129B52: nv_colon (normal.c:5179)
          > > ==11795== by 0x812310E: normal_cmd (normal.c:1152)
          > > ==11795== by 0x80E5F41: main_loop (main.c:1181)
          > > ==11795== by 0x80E5A91: main (main.c:940)
          > > (more errors of this kind follow when it happens)
          > >
          > > Bug is unfortunately difficult to reproduce. I have not found
          > > a systematic way of reproducing it but I have encountered it a
          > > couple of times.
          > >
          > > From the above stack traces, it is easy enough to understand though:
          > > xpc.xp_pattern normally points to somewhere inside ccline.cmdbuff.
          > > But at line ex_getln.c:556, it points to freed memory according to
          > > valgrind, because a previous call to put_on_cmdline() has
          > > reallocated ccline.cmdbuff. Since xpc.xp_pattern was not updated,
          > > it then points to freed memory.
          > >
          > > Looking at the code, functions that can reallocate ccline.cmdbuff are:
          > >
          > > put_on_cmdline() ...... because it may call realloc_cmdbuff()
          > > cmdline_paste_str() ... because it may call put_on_cmdline()
          > > cmdline_paste() ....... because it may call cmdline_paste_str()
          > >
          > > Whenever any of these functions is called, we should take care of
          > > reinitializing xpc.xp_pattern appropriately.
          > >
          > > Function nextwild() also calls realloc_cmdbuff() but this one
          > > is OK since it internally reinitializes xpc.xp_pattern.
          > >
          > > I attach a patch which should fix the bug.
          > >
          > > -- Dominique
          >
          >
          > I saw one additional similar issue even after my previous patch.
          >
          > ==7527== Invalid read of size 1
          > ==7527== at 0x4023572: strncmp (mc_replace_strmem.c:318)
          > ==7527== by 0x80B6656: getcmdline (ex_getln.c:557)
          > ==7527== by 0x80B94FF: getexline (ex_getln.c:2126)
          > ==7527== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
          > ==7527== by 0x8129C46: nv_colon (normal.c:5179)
          > ==7527== by 0x8123202: normal_cmd (normal.c:1152)
          > ==7527== by 0x80E6035: main_loop (main.c:1181)
          > ==7527== by 0x80E5B85: main (main.c:940)
          > ==7527== Address 0x55B1024 is 4 bytes inside a block of size 140 free'd
          > ==7527== at 0x402237F: free (vg_replace_malloc.c:233)
          > ==7527== by 0x8114345: vim_free (misc2.c:1580)
          > ==7527== by 0x80C0061: ex_window (ex_getln.c:6143)
          > ==7527== by 0x80B6BF8: getcmdline (ex_getln.c:734)
          > ==7527== by 0x80B94FF: getexline (ex_getln.c:2126)
          > ==7527== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
          > ==7527== by 0x8129C46: nv_colon (normal.c:5179)
          > ==7527== by 0x8123202: normal_cmd (normal.c:1152)
          > ==7527== by 0x80E6035: main_loop (main.c:1181)
          > ==7527== by 0x80E5B85: main (main.c:940)
          >
          > Function ex_window() may also free and reallocate ccline.cmdbuff
          > hence invalidating xpc.xp_pattern.
          >
          > I attach an update of my previous patch which should also fix this issue.

          This is tricky, since xp_pattern is separate from the allocated command
          line. It's very easy to forget updating xp_pattern. One solution would
          be to change xp_pattern from a pointer into a byte index. But there are
          several places where the start of the command line are not known.

          Another solution would be to make expand_T part of struct cmdline_info.
          Then xp_pattern can be adjusted by the function reallocating the command
          line. Code only using the expand_T doesn't need to be changed then.
          I'll look further into this.

          --
          "The sun oozed over the horizon, shoved aside darkness, crept along the
          greensward, and, with sickly fingers, pushed through the castle window,
          revealing the pillaged princess, hand at throat, crown asunder, gaping
          in frenzied horror at the sated, sodden amphibian lying beside her,
          disbelieving the magnitude of the frog's deception, screaming madly,
          "You lied!"
          - Winner of the Bulwer-Lytton contest (San Jose State University),
          wherein one writes only the first line of a bad novel

          /// 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
          -~----------~----~----~----~------~----~------~--~---
        • Dominique Pelle
          ... Until now, I saw this bug a couple of times but never found a way to reproduce it easily. Well, I just found a way to reproduce this easily with vim-7.2.6
          Message 4 of 6 , Aug 31, 2008
          • 0 Attachment
            On Sun, Mar 16, 2008 at 2:21 PM, Bram Moolenaar <Bram@...> wrote:

            > Dominique Pelle wrote:
            >
            >> > Valgrind memory checker detects the following bug in Vim-7.1.280:
            >> >
            >> > ==11795== Invalid read of size 1
            >> > ==11795== at 0x4023572: strncmp (mc_replace_strmem.c:318)
            >> > ==11795== by 0x80B6653: getcmdline (ex_getln.c:556)
            >> > ==11795== by 0x80B940B: getexline (ex_getln.c:2100)
            >> > ==11795== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
            >> > ==11795== by 0x8129B52: nv_colon (normal.c:5179)
            >> > ==11795== by 0x812310E: normal_cmd (normal.c:1152)
            >> > ==11795== by 0x80E5F41: main_loop (main.c:1181)
            >> > ==11795== by 0x80E5A91: main (main.c:940)
            >> > ==11795== Address 0x56484AA is 2 bytes inside a block of size 100 free'd
            >> > ==11795== at 0x402237F: free (vg_replace_malloc.c:233)
            >> > ==11795== by 0x8114251: vim_free (misc2.c:1580)
            >> > ==11795== by 0x80B9D01: realloc_cmdbuff (ex_getln.c:2509)
            >> > ==11795== by 0x80BA194: put_on_cmdline (ex_getln.c:2708)
            >> > ==11795== by 0x80B8B8F: getcmdline (ex_getln.c:1679)
            >> > ==11795== by 0x80B940B: getexline (ex_getln.c:2100)
            >> > ==11795== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
            >> > ==11795== by 0x8129B52: nv_colon (normal.c:5179)
            >> > ==11795== by 0x812310E: normal_cmd (normal.c:1152)
            >> > ==11795== by 0x80E5F41: main_loop (main.c:1181)
            >> > ==11795== by 0x80E5A91: main (main.c:940)
            >> > (more errors of this kind follow when it happens)
            >> >
            >> > Bug is unfortunately difficult to reproduce. I have not found
            >> > a systematic way of reproducing it but I have encountered it a
            >> > couple of times.
            >> >
            >> > From the above stack traces, it is easy enough to understand though:
            >> > xpc.xp_pattern normally points to somewhere inside ccline.cmdbuff.
            >> > But at line ex_getln.c:556, it points to freed memory according to
            >> > valgrind, because a previous call to put_on_cmdline() has
            >> > reallocated ccline.cmdbuff. Since xpc.xp_pattern was not updated,
            >> > it then points to freed memory.
            >> >
            >> > Looking at the code, functions that can reallocate ccline.cmdbuff are:
            >> >
            >> > put_on_cmdline() ...... because it may call realloc_cmdbuff()
            >> > cmdline_paste_str() ... because it may call put_on_cmdline()
            >> > cmdline_paste() ....... because it may call cmdline_paste_str()
            >> >
            >> > Whenever any of these functions is called, we should take care of
            >> > reinitializing xpc.xp_pattern appropriately.
            >> >
            >> > Function nextwild() also calls realloc_cmdbuff() but this one
            >> > is OK since it internally reinitializes xpc.xp_pattern.
            >> >
            >> > I attach a patch which should fix the bug.
            >> >
            >> > -- Dominique
            >>
            >>
            >> I saw one additional similar issue even after my previous patch.
            >>
            >> ==7527== Invalid read of size 1
            >> ==7527== at 0x4023572: strncmp (mc_replace_strmem.c:318)
            >> ==7527== by 0x80B6656: getcmdline (ex_getln.c:557)
            >> ==7527== by 0x80B94FF: getexline (ex_getln.c:2126)
            >> ==7527== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
            >> ==7527== by 0x8129C46: nv_colon (normal.c:5179)
            >> ==7527== by 0x8123202: normal_cmd (normal.c:1152)
            >> ==7527== by 0x80E6035: main_loop (main.c:1181)
            >> ==7527== by 0x80E5B85: main (main.c:940)
            >> ==7527== Address 0x55B1024 is 4 bytes inside a block of size 140 free'd
            >> ==7527== at 0x402237F: free (vg_replace_malloc.c:233)
            >> ==7527== by 0x8114345: vim_free (misc2.c:1580)
            >> ==7527== by 0x80C0061: ex_window (ex_getln.c:6143)
            >> ==7527== by 0x80B6BF8: getcmdline (ex_getln.c:734)
            >> ==7527== by 0x80B94FF: getexline (ex_getln.c:2126)
            >> ==7527== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
            >> ==7527== by 0x8129C46: nv_colon (normal.c:5179)
            >> ==7527== by 0x8123202: normal_cmd (normal.c:1152)
            >> ==7527== by 0x80E6035: main_loop (main.c:1181)
            >> ==7527== by 0x80E5B85: main (main.c:940)
            >>
            >> Function ex_window() may also free and reallocate ccline.cmdbuff
            >> hence invalidating xpc.xp_pattern.
            >>
            >> I attach an update of my previous patch which should also fix this issue.
            >
            > This is tricky, since xp_pattern is separate from the allocated command
            > line. It's very easy to forget updating xp_pattern. One solution would
            > be to change xp_pattern from a pointer into a byte index. But there are
            > several places where the start of the command line are not known.
            >
            > Another solution would be to make expand_T part of struct cmdline_info.
            > Then xp_pattern can be adjusted by the function reallocating the command
            > line. Code only using the expand_T doesn't need to be changed then.
            > I'll look further into this.

            Until now, I saw this bug a couple of times but never found a way to
            reproduce it easily. Well, I just found a way to reproduce this easily
            with vim-7.2.6 (also with gvim).

            1/ start vim with:
            algrind vim -u NONE
            2/ enter Ex command ":set nocompatible wildmenu"
            3/ put at least one command in Ex history
            :echo "foobar"
            4/ press Ex command ":e -" followed

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Dominique Pelle
            On Sun, Aug 31, 2008 at 12:06 PM, Dominique Pelle ... My apologies: I started writing the previous message and it was sent before I finished editing it! Gmail
            Message 5 of 6 , Aug 31, 2008
            • 0 Attachment
              On Sun, Aug 31, 2008 at 12:06 PM, Dominique Pelle
              <dominique.pelle@...> wrote:

              > On Sun, Mar 16, 2008 at 2:21 PM, Bram Moolenaar <Bram@...> wrote:
              >
              >> Dominique Pelle wrote:
              >>
              >>> > Valgrind memory checker detects the following bug in Vim-7.1.280:
              >>> >
              >>> > ==11795== Invalid read of size 1
              >>> > ==11795== at 0x4023572: strncmp (mc_replace_strmem.c:318)
              >>> > ==11795== by 0x80B6653: getcmdline (ex_getln.c:556)
              >>> > ==11795== by 0x80B940B: getexline (ex_getln.c:2100)
              >>> > ==11795== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
              >>> > ==11795== by 0x8129B52: nv_colon (normal.c:5179)
              >>> > ==11795== by 0x812310E: normal_cmd (normal.c:1152)
              >>> > ==11795== by 0x80E5F41: main_loop (main.c:1181)
              >>> > ==11795== by 0x80E5A91: main (main.c:940)
              >>> > ==11795== Address 0x56484AA is 2 bytes inside a block of size 100 free'd
              >>> > ==11795== at 0x402237F: free (vg_replace_malloc.c:233)
              >>> > ==11795== by 0x8114251: vim_free (misc2.c:1580)
              >>> > ==11795== by 0x80B9D01: realloc_cmdbuff (ex_getln.c:2509)
              >>> > ==11795== by 0x80BA194: put_on_cmdline (ex_getln.c:2708)
              >>> > ==11795== by 0x80B8B8F: getcmdline (ex_getln.c:1679)
              >>> > ==11795== by 0x80B940B: getexline (ex_getln.c:2100)
              >>> > ==11795== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
              >>> > ==11795== by 0x8129B52: nv_colon (normal.c:5179)
              >>> > ==11795== by 0x812310E: normal_cmd (normal.c:1152)
              >>> > ==11795== by 0x80E5F41: main_loop (main.c:1181)
              >>> > ==11795== by 0x80E5A91: main (main.c:940)
              >>> > (more errors of this kind follow when it happens)
              >>> >
              >>> > Bug is unfortunately difficult to reproduce. I have not found
              >>> > a systematic way of reproducing it but I have encountered it a
              >>> > couple of times.
              >>> >
              >>> > From the above stack traces, it is easy enough to understand though:
              >>> > xpc.xp_pattern normally points to somewhere inside ccline.cmdbuff.
              >>> > But at line ex_getln.c:556, it points to freed memory according to
              >>> > valgrind, because a previous call to put_on_cmdline() has
              >>> > reallocated ccline.cmdbuff. Since xpc.xp_pattern was not updated,
              >>> > it then points to freed memory.
              >>> >
              >>> > Looking at the code, functions that can reallocate ccline.cmdbuff are:
              >>> >
              >>> > put_on_cmdline() ...... because it may call realloc_cmdbuff()
              >>> > cmdline_paste_str() ... because it may call put_on_cmdline()
              >>> > cmdline_paste() ....... because it may call cmdline_paste_str()
              >>> >
              >>> > Whenever any of these functions is called, we should take care of
              >>> > reinitializing xpc.xp_pattern appropriately.
              >>> >
              >>> > Function nextwild() also calls realloc_cmdbuff() but this one
              >>> > is OK since it internally reinitializes xpc.xp_pattern.
              >>> >
              >>> > I attach a patch which should fix the bug.
              >>> >
              >>> > -- Dominique
              >>>
              >>>
              >>> I saw one additional similar issue even after my previous patch.
              >>>
              >>> ==7527== Invalid read of size 1
              >>> ==7527== at 0x4023572: strncmp (mc_replace_strmem.c:318)
              >>> ==7527== by 0x80B6656: getcmdline (ex_getln.c:557)
              >>> ==7527== by 0x80B94FF: getexline (ex_getln.c:2126)
              >>> ==7527== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
              >>> ==7527== by 0x8129C46: nv_colon (normal.c:5179)
              >>> ==7527== by 0x8123202: normal_cmd (normal.c:1152)
              >>> ==7527== by 0x80E6035: main_loop (main.c:1181)
              >>> ==7527== by 0x80E5B85: main (main.c:940)
              >>> ==7527== Address 0x55B1024 is 4 bytes inside a block of size 140 free'd
              >>> ==7527== at 0x402237F: free (vg_replace_malloc.c:233)
              >>> ==7527== by 0x8114345: vim_free (misc2.c:1580)
              >>> ==7527== by 0x80C0061: ex_window (ex_getln.c:6143)
              >>> ==7527== by 0x80B6BF8: getcmdline (ex_getln.c:734)
              >>> ==7527== by 0x80B94FF: getexline (ex_getln.c:2126)
              >>> ==7527== by 0x80A2F3E: do_cmdline (ex_docmd.c:995)
              >>> ==7527== by 0x8129C46: nv_colon (normal.c:5179)
              >>> ==7527== by 0x8123202: normal_cmd (normal.c:1152)
              >>> ==7527== by 0x80E6035: main_loop (main.c:1181)
              >>> ==7527== by 0x80E5B85: main (main.c:940)
              >>>
              >>> Function ex_window() may also free and reallocate ccline.cmdbuff
              >>> hence invalidating xpc.xp_pattern.
              >>>
              >>> I attach an update of my previous patch which should also fix this issue.
              >>
              >> This is tricky, since xp_pattern is separate from the allocated command
              >> line. It's very easy to forget updating xp_pattern. One solution would
              >> be to change xp_pattern from a pointer into a byte index. But there are
              >> several places where the start of the command line are not known.
              >>
              >> Another solution would be to make expand_T part of struct cmdline_info.
              >> Then xp_pattern can be adjusted by the function reallocating the command
              >> line. Code only using the expand_T doesn't need to be changed then.
              >> I'll look further into this.
              >
              > Until now, I saw this bug a couple of times but never found a way to
              > reproduce it easily. Well, I just found a way to reproduce this easily
              > with vim-7.2.6 (also with gvim).


              My apologies: I started writing the previous message and it
              was sent before I finished editing it! Gmail has some odd/dangerous
              shortcuts to send email.

              Until now, I saw the bug described in this thread a couple of times
              but never I found a way to reproduce it easily. Well, I just found a
              way to reproduce it easily with vim-7.2.6 (also with gvim).

              1/ start vim with:
              $ valgrind vim -u NONE

              2/ enter Ex command:
              :set nocompatible wildmenu

              3/ put at least one command in Ex history
              :echo "foobar"

              4/ type Ex command:
              :e -<S-Tab><S-Tab><S-Tab>

              i.e. type shift-tab 3 times after typing :e -

              After pressing shift tab 3 times, valgrind complains about:

              ==17886== Invalid read of size 1
              ==17886== at 0x4023A72: strncmp (mc_replace_strmem.c:314)
              ==17886== by 0x80B6A49: getcmdline (ex_getln.c:557)
              ==17886== by 0x80B952A: getexline (ex_getln.c:2101)
              ==17886== by 0x80A37A0: do_cmdline (ex_docmd.c:991)
              ==17886== by 0x81288B2: nv_colon (normal.c:5214)
              ==17886== by 0x8121F3D: normal_cmd (normal.c:1181)
              ==17886== by 0x80E5431: main_loop (main.c:1179)
              ==17886== by 0x80E4F7E: main (main.c:938)
              ==17886== Address 0x535f832 is 2 bytes inside a block of size 100 free'd
              ==17886== at 0x402268C: free (vg_replace_malloc.c:323)
              ==17886== by 0x811324E: vim_free (misc2.c:1629)
              ==17886== by 0x80B885E: getcmdline (ex_getln.c:1515)
              ==17886== by 0x80B952A: getexline (ex_getln.c:2101)
              ==17886== by 0x80A37A0: do_cmdline (ex_docmd.c:991)
              ==17886== by 0x81288B2: nv_colon (normal.c:5214)
              ==17886== by 0x8121F3D: normal_cmd (normal.c:1181)
              ==17886== by 0x80E5431: main_loop (main.c:1179)
              ==17886== by 0x80E4F7E: main (main.c:938)

              The patch I had attached earlier in the thread fixes it.

              -- Dominique

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Bram Moolenaar
              ... This issue is still in the todo list. Good to have something to test a solution with. -- Q: What is the difference betwee open-source and commercial
              Message 6 of 6 , Sep 1, 2008
              • 0 Attachment
                Dominique Pelle wrote:

                > >> Function ex_window() may also free and reallocate ccline.cmdbuff
                > >> hence invalidating xpc.xp_pattern.
                > >>
                > >> I attach an update of my previous patch which should also fix this issue.
                > >
                > > This is tricky, since xp_pattern is separate from the allocated command
                > > line. It's very easy to forget updating xp_pattern. One solution would
                > > be to change xp_pattern from a pointer into a byte index. But there are
                > > several places where the start of the command line are not known.
                > >
                > > Another solution would be to make expand_T part of struct cmdline_info.
                > > Then xp_pattern can be adjusted by the function reallocating the command
                > > line. Code only using the expand_T doesn't need to be changed then.
                > > I'll look further into this.
                >
                > Until now, I saw this bug a couple of times but never found a way to
                > reproduce it easily. Well, I just found a way to reproduce this easily
                > with vim-7.2.6 (also with gvim).
                >
                > 1/ start vim with:
                > algrind vim -u NONE
                > 2/ enter Ex command ":set nocompatible wildmenu"
                > 3/ put at least one command in Ex history
                > :echo "foobar"
                > 4/ press Ex command ":e -" followed

                This issue is still in the todo list. Good to have something to test a
                solution with.

                --
                Q: What is the difference betwee open-source and commercial software?
                A: If you have a problem with commercial software you can call a phone
                number and they will tell you it might be solved in a future version.
                For open-source software there isn't a phone number to call, but you
                get the solution within a day.

                /// 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.