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

Patch 7.4.402

Expand Messages
  • Bram Moolenaar
    Patch 7.4.402 Problem: Test 72 crashes under certain conditions. (Kazunobu Kuriyama) Solution: Clear the whole bufinfo_T early. Files: src/undo.c ...
    Message 1 of 7 , Aug 12, 2014
      Patch 7.4.402
      Problem: Test 72 crashes under certain conditions. (Kazunobu Kuriyama)
      Solution: Clear the whole bufinfo_T early.
      Files: src/undo.c


      *** ../vim-7.4.401/src/undo.c 2014-08-10 13:34:59.064785459 +0200
      --- src/undo.c 2014-08-12 20:08:23.915373819 +0200
      ***************
      *** 929,935 ****
      undo_flush(bi)
      bufinfo_T *bi;
      {
      ! if (bi->bi_used > 0)
      {
      crypt_encode_inplace(bi->bi_state, bi->bi_buffer, bi->bi_used);
      if (fwrite(bi->bi_buffer, bi->bi_used, (size_t)1, bi->bi_fp) != 1)
      --- 929,935 ----
      undo_flush(bi)
      bufinfo_T *bi;
      {
      ! if (bi->bi_buffer != NULL && bi->bi_used > 0)
      {
      crypt_encode_inplace(bi->bi_state, bi->bi_buffer, bi->bi_used);
      if (fwrite(bi->bi_buffer, bi->bi_used, (size_t)1, bi->bi_fp) != 1)
      ***************
      *** 1573,1582 ****
      #endif
      bufinfo_T bi;

      ! #ifdef FEAT_CRYPT
      ! bi.bi_state = NULL;
      ! bi.bi_buffer = NULL;
      ! #endif

      if (name == NULL)
      {
      --- 1573,1579 ----
      #endif
      bufinfo_T bi;

      ! vim_memset(&bi, 0, sizeof(bi));

      if (name == NULL)
      {
      ***************
      *** 1861,1866 ****
      --- 1858,1864 ----
      #endif
      bufinfo_T bi;

      + vim_memset(&bi, 0, sizeof(bi));
      if (name == NULL)
      {
      file_name = u_get_undo_file_name(curbuf->b_ffname, TRUE);
      ***************
      *** 1905,1914 ****
      }
      bi.bi_buf = curbuf;
      bi.bi_fp = fp;
      - #ifdef FEAT_CRYPT
      - bi.bi_state = NULL;
      - bi.bi_buffer = NULL;
      - #endif

      /*
      * Read the undo file header.
      --- 1903,1908 ----
      *** ../vim-7.4.401/src/version.c 2014-08-10 16:31:47.376709213 +0200
      --- src/version.c 2014-08-12 20:11:13.879372598 +0200
      ***************
      *** 743,744 ****
      --- 743,746 ----
      { /* Add new patch number below this line */
      + /**/
      + 402,
      /**/

      --
      Far back in the mists of ancient time, in the great and glorious days of the
      former Galactic Empire, life was wild, rich and largely tax free.
      Mighty starships plied their way between exotic suns, seeking adventure and
      reward among the furthest reaches of Galactic space. In those days, spirits
      were brave, the stakes were high, men were real men, women were real women
      and small furry creatures from Alpha Centauri were real small furry creatures
      from Alpha Centauri. And all dared to brave unknown terrors, to do mighty
      deeds, to boldly split infinitives that no man had split before -- and thus
      was the Empire forged.
      -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ an exciting new programming language -- http://www.Zimbu.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

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

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/d/optout.
    • Dominique PellĂ©
      ... Test 72 no longer segfaults after this patch. However, running it under valgrind shows access to uninitialized memory: ==19752== Memcheck, a memory error
      Message 2 of 7 , Aug 12, 2014
        Bram Moolenaar wrote:

        > Patch 7.4.402
        > Problem: Test 72 crashes under certain conditions. (Kazunobu Kuriyama)
        > Solution: Clear the whole bufinfo_T early.
        > Files: src/undo.c

        Test 72 no longer segfaults after this patch. However,
        running it under valgrind shows access to uninitialized
        memory:

        ==19752== Memcheck, a memory error detector
        ==19752== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
        ==19752== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
        ==19752== Command: ../vim -u unix.vim -U NONE --noplugin -s dotest.in test72.in
        ==19752== Parent PID: 19751
        ==19752==
        ==19752== Use of uninitialised value of size 8
        ==19752== at 0x4104E9: bf_e_block (blowfish.c:360)
        ==19752== by 0x410D1B: bf_e_cblock (blowfish.c:396)
        ==19752== by 0x41147A: crypt_blowfish_encode (blowfish.c:618)
        ==19752== by 0x41517B: crypt_encode (crypt.c:448)
        ==19752== by 0x4C127D: ml_encrypt_data (memline.c:4841)
        ==19752== by 0x5DE3AA: mf_write_block (memfile.c:1138)
        ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
        ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
        ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
        ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
        ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
        ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
        ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
        ==19752== by 0x42573D: insertchar (edit.c:6051)
        ==19752== by 0x42528E: insert_special (edit.c:5832)

        ... many more errors...

        ==19752== Syscall param write(buf) points to uninitialised byte(s)
        ==19752== at 0x662C040: __write_nocancel (syscall-template.S:82)
        ==19752== by 0x498B7D: write_eintr (fileio.c:10433)
        ==19752== by 0x5DE3D4: mf_write_block (memfile.c:1144)
        ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
        ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
        ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
        ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
        ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
        ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
        ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
        ==19752== by 0x42573D: insertchar (edit.c:6051)
        ==19752== by 0x42528E: insert_special (edit.c:5832)
        ==19752== by 0x41D9F3: edit (edit.c:1494)
        ==19752== by 0x4FEA0C: invoke_edit (normal.c:9062)
        ==19752== by 0x4FE9A5: nv_edit (normal.c:9035)
        ==19752== Address 0x76f0510 is 4,080 bytes inside a block of size 4,096 alloc'd
        ==19752== at 0x4C2C857: malloc (vg_replace_malloc.c:291)
        ==19752== by 0x4DFEDA: lalloc (misc2.c:921)
        ==19752== by 0x4DFDE7: alloc (misc2.c:820)
        ==19752== by 0x4C11C0: ml_encrypt_data (memline.c:4829)
        ==19752== by 0x5DE3AA: mf_write_block (memfile.c:1138)
        ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
        ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
        ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
        ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
        ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
        ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
        ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
        ==19752== by 0x42573D: insertchar (edit.c:6051)
        ==19752== by 0x42528E: insert_special (edit.c:5832)
        ==19752== by 0x41D9F3: edit (edit.c:1494)

        I assume it is a bug. In some rare cases,
        reading uninitialized memory can be one source
        of randomness. If that was the case, it would be
        good to indicate it in a comment. But more likely
        it's a bug.

        Regards
        Dominique

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

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/d/optout.
      • Bram Moolenaar
        ... I assume this already happened before 7.4.402. But I also assume that if it happened before 7.4.399 you would already have reported it before, thus it
        Message 3 of 7 , Aug 12, 2014
          Dominique wrote:

          > Bram Moolenaar wrote:
          >
          > > Patch 7.4.402
          > > Problem: Test 72 crashes under certain conditions. (Kazunobu Kuriyama)
          > > Solution: Clear the whole bufinfo_T early.
          > > Files: src/undo.c
          >
          > Test 72 no longer segfaults after this patch. However,
          > running it under valgrind shows access to uninitialized
          > memory:
          >
          > ==19752== Memcheck, a memory error detector
          > ==19752== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
          > ==19752== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
          > ==19752== Command: ../vim -u unix.vim -U NONE --noplugin -s dotest.in test72.in
          > ==19752== Parent PID: 19751
          > ==19752==
          > ==19752== Use of uninitialised value of size 8
          > ==19752== at 0x4104E9: bf_e_block (blowfish.c:360)
          > ==19752== by 0x410D1B: bf_e_cblock (blowfish.c:396)
          > ==19752== by 0x41147A: crypt_blowfish_encode (blowfish.c:618)
          > ==19752== by 0x41517B: crypt_encode (crypt.c:448)
          > ==19752== by 0x4C127D: ml_encrypt_data (memline.c:4841)
          > ==19752== by 0x5DE3AA: mf_write_block (memfile.c:1138)
          > ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
          > ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
          > ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
          > ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
          > ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
          > ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
          > ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
          > ==19752== by 0x42573D: insertchar (edit.c:6051)
          > ==19752== by 0x42528E: insert_special (edit.c:5832)
          >
          > ... many more errors...
          >
          > ==19752== Syscall param write(buf) points to uninitialised byte(s)
          > ==19752== at 0x662C040: __write_nocancel (syscall-template.S:82)
          > ==19752== by 0x498B7D: write_eintr (fileio.c:10433)
          > ==19752== by 0x5DE3D4: mf_write_block (memfile.c:1144)
          > ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
          > ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
          > ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
          > ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
          > ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
          > ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
          > ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
          > ==19752== by 0x42573D: insertchar (edit.c:6051)
          > ==19752== by 0x42528E: insert_special (edit.c:5832)
          > ==19752== by 0x41D9F3: edit (edit.c:1494)
          > ==19752== by 0x4FEA0C: invoke_edit (normal.c:9062)
          > ==19752== by 0x4FE9A5: nv_edit (normal.c:9035)
          > ==19752== Address 0x76f0510 is 4,080 bytes inside a block of size 4,096 alloc'd
          > ==19752== at 0x4C2C857: malloc (vg_replace_malloc.c:291)
          > ==19752== by 0x4DFEDA: lalloc (misc2.c:921)
          > ==19752== by 0x4DFDE7: alloc (misc2.c:820)
          > ==19752== by 0x4C11C0: ml_encrypt_data (memline.c:4829)
          > ==19752== by 0x5DE3AA: mf_write_block (memfile.c:1138)
          > ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
          > ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
          > ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
          > ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
          > ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
          > ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
          > ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
          > ==19752== by 0x42573D: insertchar (edit.c:6051)
          > ==19752== by 0x42528E: insert_special (edit.c:5832)
          > ==19752== by 0x41D9F3: edit (edit.c:1494)
          >
          > I assume it is a bug. In some rare cases,
          > reading uninitialized memory can be one source
          > of randomness. If that was the case, it would be
          > good to indicate it in a comment. But more likely
          > it's a bug.

          I assume this already happened before 7.4.402. But I also assume that
          if it happened before 7.4.399 you would already have reported it before,
          thus it would be related to 7.4.399.

          --
          "Making it up? Why should I want to make anything up? Life's bad enough
          as it is without wanting to invent any more of it."
          -- Marvin, the Paranoid Android in Douglas Adams'
          "The Hitchhiker's Guide to the Galaxy"

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ an exciting new programming language -- http://www.Zimbu.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

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

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/d/optout.
        • Charles Cooper
          ... As long as you all are working on undo.c, there is a compile warning with 32 bit Windows MSVC undo.c(995) : warning C4244: = : conversion from long_u
          Message 4 of 7 , Aug 13, 2014
            On Tuesday, August 12, 2014 5:39:05 PM UTC-4, Bram Moolenaar wrote:
            > Dominique wrote:
            > > Bram Moolenaar wrote:
            > > > Patch 7.4.402
            > > > Problem: Test 72 crashes under certain conditions. (Kazunobu Kuriyama)
            > > > Solution: Clear the whole bufinfo_T early.
            > > > Files: src/undo.c
            > >
            > > Test 72 no longer segfaults after this patch. However,
            > > running it under valgrind shows access to uninitialized
            > > memory:
            > >

            As long as you all are working on undo.c, there is a compile warning with 32 bit Windows MSVC

            undo.c(995) : warning C4244: '=' : conversion from 'long_u' to 'char_u', possible loss of data

            which can be eliminated with a cast

            *** a/vim/src/undo.c Sun Aug 10 13:34:30 2014
            --- b/vim/src/undo.c Tue Aug 12 09:49:48 2014
            ***************
            *** 992,998 ****
            int bufi = 0;

            for (i = len - 1; i >= 0; --i)
            ! buf[bufi++] = nr >> (i * 8);
            return undo_write(bi, buf, (size_t)len);
            }

            --- 992,998 ----
            int bufi = 0;

            for (i = len - 1; i >= 0; --i)
            ! buf[bufi++] = (char_u)(nr >> (i * 8));
            return undo_write(bi, buf, (size_t)len);
            }


            Charlie

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

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/d/optout.
          • Bram Moolenaar
            ... Turns out these valgrind warnings are already present before 7.4.399, once test 72 has been fixed. It was actually testing zip crypt twice. After applying
            Message 5 of 7 , Aug 13, 2014
              Dominique wrote:

              > Bram Moolenaar wrote:
              >
              > > Patch 7.4.402
              > > Problem: Test 72 crashes under certain conditions. (Kazunobu Kuriyama)
              > > Solution: Clear the whole bufinfo_T early.
              > > Files: src/undo.c
              >
              > Test 72 no longer segfaults after this patch. However,
              > running it under valgrind shows access to uninitialized
              > memory:
              >
              > ==19752== Memcheck, a memory error detector
              > ==19752== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
              > ==19752== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
              > ==19752== Command: ../vim -u unix.vim -U NONE --noplugin -s dotest.in test72.in
              > ==19752== Parent PID: 19751
              > ==19752==
              > ==19752== Use of uninitialised value of size 8
              > ==19752== at 0x4104E9: bf_e_block (blowfish.c:360)
              > ==19752== by 0x410D1B: bf_e_cblock (blowfish.c:396)
              > ==19752== by 0x41147A: crypt_blowfish_encode (blowfish.c:618)
              > ==19752== by 0x41517B: crypt_encode (crypt.c:448)
              > ==19752== by 0x4C127D: ml_encrypt_data (memline.c:4841)
              > ==19752== by 0x5DE3AA: mf_write_block (memfile.c:1138)
              > ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
              > ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
              > ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
              > ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
              > ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
              > ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
              > ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
              > ==19752== by 0x42573D: insertchar (edit.c:6051)
              > ==19752== by 0x42528E: insert_special (edit.c:5832)
              >
              > ... many more errors...
              >
              > ==19752== Syscall param write(buf) points to uninitialised byte(s)
              > ==19752== at 0x662C040: __write_nocancel (syscall-template.S:82)
              > ==19752== by 0x498B7D: write_eintr (fileio.c:10433)
              > ==19752== by 0x5DE3D4: mf_write_block (memfile.c:1144)
              > ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
              > ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
              > ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
              > ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
              > ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
              > ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
              > ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
              > ==19752== by 0x42573D: insertchar (edit.c:6051)
              > ==19752== by 0x42528E: insert_special (edit.c:5832)
              > ==19752== by 0x41D9F3: edit (edit.c:1494)
              > ==19752== by 0x4FEA0C: invoke_edit (normal.c:9062)
              > ==19752== by 0x4FE9A5: nv_edit (normal.c:9035)
              > ==19752== Address 0x76f0510 is 4,080 bytes inside a block of size 4,096 alloc'd
              > ==19752== at 0x4C2C857: malloc (vg_replace_malloc.c:291)
              > ==19752== by 0x4DFEDA: lalloc (misc2.c:921)
              > ==19752== by 0x4DFDE7: alloc (misc2.c:820)
              > ==19752== by 0x4C11C0: ml_encrypt_data (memline.c:4829)
              > ==19752== by 0x5DE3AA: mf_write_block (memfile.c:1138)
              > ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
              > ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
              > ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
              > ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
              > ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
              > ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
              > ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
              > ==19752== by 0x42573D: insertchar (edit.c:6051)
              > ==19752== by 0x42528E: insert_special (edit.c:5832)
              > ==19752== by 0x41D9F3: edit (edit.c:1494)
              >
              > I assume it is a bug. In some rare cases,
              > reading uninitialized memory can be one source
              > of randomness. If that was the case, it would be
              > good to indicate it in a comment. But more likely
              > it's a bug.

              Turns out these valgrind warnings are already present before 7.4.399,
              once test 72 has been fixed. It was actually testing zip crypt twice.
              After applying the fix for the text I get the same errors before patch
              7.4.399.

              Still haven't figured out why, they only appear twice, even when using
              blowfish twice, thus apparently it only happens the very first time Vim
              uses blowfish.

              --
              If Pacman had affected us as kids we'd be running around in dark rooms,
              munching pills and listening to repetitive music.
              -- Marcus Brigstocke

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ an exciting new programming language -- http://www.Zimbu.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

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

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/d/optout.
            • Christian Brabandt
              Hi Bram! ... FWIW, I don t see that error with 7.4.398 Best Christian -- Man braucht nicht immer einen Handwerker zu bestellen. Man kann sein Heim auch selbst
              Message 6 of 7 , Aug 13, 2014
                Hi Bram!

                On Mi, 13 Aug 2014, Bram Moolenaar wrote:

                >
                > Dominique wrote:
                >
                > > Bram Moolenaar wrote:
                > >
                > > > Patch 7.4.402
                > > > Problem: Test 72 crashes under certain conditions. (Kazunobu Kuriyama)
                > > > Solution: Clear the whole bufinfo_T early.
                > > > Files: src/undo.c
                > >
                > > Test 72 no longer segfaults after this patch. However,
                > > running it under valgrind shows access to uninitialized
                > > memory:
                > >
                > > ==19752== Memcheck, a memory error detector
                > > ==19752== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
                > > ==19752== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
                > > ==19752== Command: ../vim -u unix.vim -U NONE --noplugin -s dotest.in test72.in
                > > ==19752== Parent PID: 19751
                > > ==19752==
                > > ==19752== Use of uninitialised value of size 8
                > > ==19752== at 0x4104E9: bf_e_block (blowfish.c:360)
                > > ==19752== by 0x410D1B: bf_e_cblock (blowfish.c:396)
                > > ==19752== by 0x41147A: crypt_blowfish_encode (blowfish.c:618)
                > > ==19752== by 0x41517B: crypt_encode (crypt.c:448)
                > > ==19752== by 0x4C127D: ml_encrypt_data (memline.c:4841)
                > > ==19752== by 0x5DE3AA: mf_write_block (memfile.c:1138)
                > > ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
                > > ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
                > > ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
                > > ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
                > > ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
                > > ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
                > > ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
                > > ==19752== by 0x42573D: insertchar (edit.c:6051)
                > > ==19752== by 0x42528E: insert_special (edit.c:5832)
                > >
                > > ... many more errors...
                > >
                > > ==19752== Syscall param write(buf) points to uninitialised byte(s)
                > > ==19752== at 0x662C040: __write_nocancel (syscall-template.S:82)
                > > ==19752== by 0x498B7D: write_eintr (fileio.c:10433)
                > > ==19752== by 0x5DE3D4: mf_write_block (memfile.c:1144)
                > > ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
                > > ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
                > > ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
                > > ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
                > > ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
                > > ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
                > > ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
                > > ==19752== by 0x42573D: insertchar (edit.c:6051)
                > > ==19752== by 0x42528E: insert_special (edit.c:5832)
                > > ==19752== by 0x41D9F3: edit (edit.c:1494)
                > > ==19752== by 0x4FEA0C: invoke_edit (normal.c:9062)
                > > ==19752== by 0x4FE9A5: nv_edit (normal.c:9035)
                > > ==19752== Address 0x76f0510 is 4,080 bytes inside a block of size 4,096 alloc'd
                > > ==19752== at 0x4C2C857: malloc (vg_replace_malloc.c:291)
                > > ==19752== by 0x4DFEDA: lalloc (misc2.c:921)
                > > ==19752== by 0x4DFDE7: alloc (misc2.c:820)
                > > ==19752== by 0x4C11C0: ml_encrypt_data (memline.c:4829)
                > > ==19752== by 0x5DE3AA: mf_write_block (memfile.c:1138)
                > > ==19752== by 0x5DE2AC: mf_write (memfile.c:1094)
                > > ==19752== by 0x5DD8E7: mf_sync (memfile.c:592)
                > > ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282)
                > > ==19752== by 0x4A0CE1: updatescript (getchar.c:1581)
                > > ==19752== by 0x4A04C1: gotchars (getchar.c:1284)
                > > ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424)
                > > ==19752== by 0x4A0DAA: vgetc (getchar.c:1637)
                > > ==19752== by 0x42573D: insertchar (edit.c:6051)
                > > ==19752== by 0x42528E: insert_special (edit.c:5832)
                > > ==19752== by 0x41D9F3: edit (edit.c:1494)
                > >
                > > I assume it is a bug. In some rare cases,
                > > reading uninitialized memory can be one source
                > > of randomness. If that was the case, it would be
                > > good to indicate it in a comment. But more likely
                > > it's a bug.
                >
                > Turns out these valgrind warnings are already present before 7.4.399,
                > once test 72 has been fixed. It was actually testing zip crypt twice.
                > After applying the fix for the text I get the same errors before patch
                > 7.4.399.
                >
                > Still haven't figured out why, they only appear twice, even when using
                > blowfish twice, thus apparently it only happens the very first time Vim
                > uses blowfish.

                FWIW, I don't see that error with 7.4.398

                Best
                Christian
                --
                Man braucht nicht immer einen Handwerker zu bestellen. Man kann sein
                Heim auch selbst ruinieren.
                -- Ephraim Kishon (alias Ferenc Hoffmann)

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

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/d/optout.
              • Bram Moolenaar
                ... Mike Williams regularly sends me a patch for these, I just included the latest. -- How To Keep A Healthy Level Of Insanity: 11. Specify that your
                Message 7 of 7 , Aug 13, 2014
                  Charles Cooper wrote:

                  > On Tuesday, August 12, 2014 5:39:05 PM UTC-4, Bram Moolenaar wrote:
                  > > Dominique wrote:
                  > > > Bram Moolenaar wrote:
                  > > > > Patch 7.4.402
                  > > > > Problem: Test 72 crashes under certain conditions. (Kazunobu Kuriyama)
                  > > > > Solution: Clear the whole bufinfo_T early.
                  > > > > Files: src/undo.c
                  > > >
                  > > > Test 72 no longer segfaults after this patch. However,
                  > > > running it under valgrind shows access to uninitialized
                  > > > memory:
                  > > >
                  >
                  > As long as you all are working on undo.c, there is a compile warning
                  > with 32 bit Windows MSVC
                  >
                  > undo.c(995) : warning C4244: '=' : conversion from 'long_u' to
                  > 'char_u', possible loss of data
                  >
                  > which can be eliminated with a cast

                  Mike Williams regularly sends me a patch for these, I just included the
                  latest.


                  --
                  How To Keep A Healthy Level Of Insanity:
                  11. Specify that your drive-through order is "to go".

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ an exciting new programming language -- http://www.Zimbu.org ///
                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

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

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/d/optout.
                Your message has been successfully submitted and would be delivered to recipients shortly.