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

Re: Patch 7.3.1182

Expand Messages
  • Ajit Thakkar
    Ken, sorry for the false report. The problem disappeared with a fresh build after the equivalent of a make clean. Ben, yes, I had meant a directory junction
    Message 1 of 12 , Jun 13, 2013
    • 0 Attachment
      Ken, sorry for the false report. The problem disappeared with a fresh build after the equivalent of a make clean.

      Ben, yes, I had meant a directory junction created with mklink /J

      Ajit

      --
      --
      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/groups/opt_out.
    • Ajit Thakkar
      I was too quick to say the problems disappeared. With 32-bit gvim 7.3.1182 and later, on 64-bit Win 7 SP1, a hang is often obtained with the simplest of
      Message 2 of 12 , Jun 15, 2013
      • 0 Attachment
        I was too quick to say the problems disappeared.

        With 32-bit gvim 7.3.1182 and later, on 64-bit Win 7 SP1, a hang is often obtained with the simplest of procedures:

        gvim -u NONE a.txt
        Make any edit
        :w

        It happens in many, but not all, of the subdirectories associated with my user identity, ie at a level below c:\users\ajit
        For example, there is no such problem in the TEMP directory c:\users\ajit\AppData\Local\Temp

        In a different subdirectory, this procedure gave me an
        E293: block was not locked
        Then trying :w again led to a hang.

        The exe was compiled with features=normal using a MinGW version of gcc 4.8.0

        There were no such problems with gvim 7.3.1181 or earlier to which I have reverted.

        --
        --
        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/groups/opt_out.
      • Bram Moolenaar
        ... Does this change when you manually change the value of backupcopy ? Since you say the problem happens when using :w it should. I actually don t see why
        Message 3 of 12 , Jun 16, 2013
        • 0 Attachment
          Ajit Thakkar wrote:

          > I was too quick to say the problems disappeared.
          >
          > With 32-bit gvim 7.3.1182 and later, on 64-bit Win 7 SP1, a hang is
          > often obtained with the simplest of procedures:
          >
          > gvim -u NONE a.txt
          > Make any edit
          > :w
          >
          > It happens in many, but not all, of the subdirectories associated with
          > my user identity, ie at a level below c:\users\ajit
          > For example, there is no such problem in the TEMP directory
          > c:\users\ajit\AppData\Local\Temp
          >
          > In a different subdirectory, this procedure gave me an
          > E293: block was not locked
          > Then trying :w again led to a hang.
          >
          > The exe was compiled with features=normal using a MinGW version of gcc
          > 4.8.0
          >
          > There were no such problems with gvim 7.3.1181 or earlier to which I
          > have reverted.

          Does this change when you manually change the value of 'backupcopy'?
          Since you say the problem happens when using ":w" it should.

          I actually don't see why a wrong value of 'backupcopy' causes a hang.

          --
          hundred-and-one symptoms of being an internet addict:
          222. You send more than 20 personal e-mails a day.

          /// 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/groups/opt_out.
        • Ajit Thakkar
          Setting backupcopy=yes does seem to solve the problem, at least on three tries. Without it, the behavior is erratic. Just now, in the last 5 minutes, I got on
          Message 4 of 12 , Jun 16, 2013
          • 0 Attachment
            Setting backupcopy=yes does seem to solve the problem, at least on three tries. 

            Without it, the behavior is erratic. Just now, in the last 5 minutes, I got on different occasions an E510, an E222, an E211, and a backup file named yyyy (but all the y's had an umlaut on them)  left behind in the current directory. 

            It gives me the impression that some random access to memory is taking place, as if there were an attempt to use an uninitialized value or an array element with an index outside the declared range.




            On Sun, Jun 16, 2013 at 9:18 AM, Bram Moolenaar <Bram@...> wrote:

            Ajit Thakkar wrote:

            > I was too quick to say the problems disappeared.
            >
            > With 32-bit gvim 7.3.1182 and later, on 64-bit Win 7 SP1, a hang is
            > often obtained with the simplest of procedures:
            >
            > gvim -u NONE a.txt
            > Make any edit
            > :w
            >
            > It happens in many, but not all, of the subdirectories associated with
            > my user identity, ie at a level below c:\users\ajit
            > For example, there is no such problem in the TEMP directory
            > c:\users\ajit\AppData\Local\Temp
            >
            > In a different subdirectory, this procedure gave me an
            > E293: block was not locked
            > Then trying :w again led to a hang.
            >
            > The exe was compiled with features=normal using a MinGW version of gcc
            > 4.8.0
            >
            > There were no such problems with gvim 7.3.1181 or earlier to which I
            > have reverted.

            Does this change when you manually change the value of 'backupcopy'?
            Since you say the problem happens when using ":w" it should.

            I actually don't see why a wrong value of 'backupcopy' causes a hang.

            --
            hundred-and-one symptoms of being an internet addict:
            222. You send more than 20 personal e-mails a day.

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



            --
            Ajit Thakkar, PhD, FCIC

            Professor of Chemistry
            University of New Brunswick
            Fredericton, NB, Canada
            http://www.unb.ca/chem/ajit/

            Editor, Computational & Theoretical Chemistry
            http://www.journals.elsevier.com/computational-and-theoretical-chemistry/#description

            --
            --
            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/groups/opt_out.
             
             
          • Bram Moolenaar
            ... I hope someone with a good Windows debugger can find out what s going wrong. Can you specify what links are on these files exactly? Preferably by listing
            Message 5 of 12 , Jun 16, 2013
            • 0 Attachment
              Ajit Thakkar wrote:

              > Setting backupcopy=yes does seem to solve the problem, at least on three
              > tries.
              >
              > Without it, the behavior is erratic. Just now, in the last 5 minutes, I got
              > on different occasions an E510, an E222, an E211, and a backup file named
              > yyyy (but all the y's had an umlaut on them) left behind in the current
              > directory.
              >
              > It gives me the impression that some random access to memory is taking
              > place, as if there were an attempt to use an uninitialized value or an
              > array element with an index outside the declared range.

              I hope someone with a good Windows debugger can find out what's going
              wrong.

              Can you specify what links are on these files exactly? Preferably by
              listing the sequence of commands used to create the file and the links.

              --
              hundred-and-one symptoms of being an internet addict:
              230. You spend your Friday nights typing away at your keyboard

              /// 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/groups/opt_out.
            • Ken Takata
              Hi, ... I had a report from Yukihiro Nakadaira that mch_is_symbolic_link() has a bug when encoding is same as the current codepage. I didn t notice because I
              Message 6 of 12 , Jun 16, 2013
              • 0 Attachment
                Hi,

                2013/06/16 San 23:01:39 UTC+9 Bram Moolenaar wrote:
                > Ajit Thakkar wrote:
                >
                > > Setting backupcopy=yes does seem to solve the problem, at least on three
                > > tries.
                > >
                > > Without it, the behavior is erratic. Just now, in the last 5 minutes, I got
                > > on different occasions an E510, an E222, an E211, and a backup file named
                > > yyyy (but all the y's had an umlaut on them) left behind in the current
                > > directory.
                > >
                > > It gives me the impression that some random access to memory is taking
                > > place, as if there were an attempt to use an uninitialized value or an
                > > array element with an index outside the declared range.
                >
                > I hope someone with a good Windows debugger can find out what's going
                > wrong.
                >
                > Can you specify what links are on these files exactly? Preferably by
                > listing the sequence of commands used to create the file and the links.

                I had a report from Yukihiro Nakadaira that mch_is_symbolic_link() has
                a bug when 'encoding' is same as the current codepage. I didn't notice
                because I mainly used enc=utf-8 which is different form the current codepage.
                Attached patch fixes this bug, but I'm not sure this is the cause of the hang.

                Best regards,
                Ken Takata

                --
                --
                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/groups/opt_out.
              • Bram Moolenaar
                ... Thanks for the patch. Ajit, please let us know if this fixes your problem. -- The term free software is defined by Richard M. Stallman as being software
                Message 7 of 12 , Jun 16, 2013
                • 0 Attachment
                  Ken Takata wrote:

                  > 2013/06/16 San 23:01:39 UTC+9 Bram Moolenaar wrote:
                  > > Ajit Thakkar wrote:
                  > >
                  > > > Setting backupcopy=yes does seem to solve the problem, at least on three
                  > > > tries.
                  > > >
                  > > > Without it, the behavior is erratic. Just now, in the last 5 minutes, I got
                  > > > on different occasions an E510, an E222, an E211, and a backup file named
                  > > > yyyy (but all the y's had an umlaut on them) left behind in the current
                  > > > directory.
                  > > >
                  > > > It gives me the impression that some random access to memory is taking
                  > > > place, as if there were an attempt to use an uninitialized value or an
                  > > > array element with an index outside the declared range.
                  > >
                  > > I hope someone with a good Windows debugger can find out what's going
                  > > wrong.
                  > >
                  > > Can you specify what links are on these files exactly? Preferably by
                  > > listing the sequence of commands used to create the file and the links.
                  >
                  > I had a report from Yukihiro Nakadaira that mch_is_symbolic_link() has
                  > a bug when 'encoding' is same as the current codepage. I didn't notice
                  > because I mainly used enc=utf-8 which is different form the current codepage.
                  > Attached patch fixes this bug, but I'm not sure this is the cause of the hang.

                  Thanks for the patch.

                  Ajit, please let us know if this fixes your problem.

                  --
                  The term "free software" is defined by Richard M. Stallman as
                  being software that isn't necessarily for free. Confusing?
                  Let's call it "Stallman software" then!
                  -- Bram Moolenaar

                  /// 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/groups/opt_out.
                • Ajit Thakkar
                  Thank you very much, Ken. This patch seems to fix the problems I was experiencing. -- -- You received this message from the vim_dev maillist. Do not
                  Message 8 of 12 , Jun 16, 2013
                  • 0 Attachment
                    Thank you very much, Ken. This patch seems to fix the problems I was experiencing. 

                    --
                    --
                    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/groups/opt_out.
                     
                     
                  Your message has been successfully submitted and would be delivered to recipients shortly.