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

Re: Patch 7.3.1182

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.