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

Re: Coulpe of odd [repeatable] crashes in vim 7

Expand Messages
  • Bram Moolenaar
    ... Did you make sure the autocommand doesn t switch to another buffer, doesn t move the cursor, etc? ... I suspect that the FileChangedRO command messes with
    Message 1 of 24 , Apr 4 3:51 AM
      Neil Bird wrote:

      > I am looking into this, but I'm not sure I'm going to get anywhere.
      > I have two crashes which I'd *hoped* were the same [may still
      > fundamentally be] but are actually happening in different places.
      >
      > The first happened in 6.4 as well, I just made sure I never did that
      > sequence of events!
      >
      > The repeatability is going to be an issue as it stems from a
      > slightly modified version of a SourceSafe plugin I use (from
      > vim.sf.net IIRC). This is all pure vim-script, but runs 'system()'
      > commands and so no-one else without SourceSafe is going to be able to
      > obviously trigger it :-/
      >
      > I have an autocmd set up so that if I try to edit a read-only file
      > that has been found in SourceSafe, it asks if I want to check it out,
      > and then does so.
      > The crashes occur when vim itself triggers the edit (q.v.), just
      > after the file has been checked out and is in the process of being
      > read back in.

      Did you make sure the autocommand doesn't switch to another buffer,
      doesn't move the cursor, etc?

      > #1 [also in vim 6.4, but I couldn't tell you where; the 7.0c crash in in
      > tab-related code] is in diffmode, when 'dp' passing a diff from one file to a
      > read-only file, causing check-out:
      >
      > #0 0x08084d38 in ex_diffgetput (eap=0xbfb04da0) at diff.c:2062
      > #1 0x080853ad in nv_diffgetput (put=1) at diff.c:1935
      > #2 0x081237a5 in nv_put (cap=0xbfb04ec0) at normal.c:8900
      > #3 0x0812245b in normal_cmd (oap=0xbfb04f30, toplevel=1) at normal.c:1138
      > #4 0x080eaa42 in main_loop (cmdwin=0, noexmode=0) at main.c:1123
      > #5 0x080ede5b in main (argc=75, argv=0x4b) at main.c:913
      >
      >
      > if (dp->df_lnum[idx_cur] > eap->line2 + off)
      >
      >
      > Where dp is apparently invalid:
      >
      > (gdb) print *dp
      > Cannot access memory at address 0x2a735c3b
      >
      >
      > dp from:
      > for (dp = curtab->tp_first_diff; dp != NULL; )
      >
      > Where:
      >
      > (gdb) print *curtab
      > $5 = {tp_next = 0x0, tp_topframe = 0x87bfeb8, tp_curwin = 0x0, tp_prevwin =
      > 0x0, tp_firstwin = 0x0, tp_lastwin = 0x0, tp_old_Rows = 0, tp_old_Columns = 0,
      > tp_prev_which_scrollbars = {1, 1, 0}, tp_first_diff = 0x881b5f8, tp_diffbuf =
      > {0x8b45390, 0x87bebf0, 0x0, 0x0}, tp_diff_invalid = 0, tp_snapshot = 0x0}

      I suspect that the FileChangedRO command messes with the buffer in such
      a way that the diff info becomes invalid. That means you change the
      buffer under the fingers of the code that works on it.

      I'll add a check for FileChangedRO before going into the loop. That
      should help to avoid the crash. At least it worked for the way I could
      reproduce the crash.

      > #2 is correcting a spelling 'z=' in a readonly file as above. Crashes in
      > memline.c:3096:ml_flush_line() at:
      >
      > vim_free(new_line);
      >
      > new_line has a value, but is presumably borked.
      >
      >
      > This is on Fedora Core 3 with a GTK2 enabled build (but crashes in term &
      > in GUI mode).

      I can't guess why this happens and I can't reproduce it.

      I think I better enforce that FileChangedRO does not change to another
      buffer to avoid all these troubles. Changing the text probably needs to
      be allowed, thus there might still be a problem with diff mode.

      --
      Westheimer's Discovery:
      A couple of months in the laboratory can
      frequently save a couple of hours in the library.

      /// 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://www.ICCF.nl ///
    • Neil Bird
      Around about 04/04/06 11:51, Bram Moolenaar typed ... ... I ll trawl through it, and see if I can see anything. I don t think it does though. However, it
      Message 2 of 24 , Apr 5 1:59 AM
        Around about 04/04/06 11:51, Bram Moolenaar typed ...
        > Did you make sure the autocommand doesn't switch to another buffer,
        > doesn't move the cursor, etc?

        I'll trawl through it, and see if I can see anything. I don't think it
        does though. However, it *does* parse the output of the command-line
        SourceSafe commands somehow; they may go into a temp buffer.


        > I'll add a check for FileChangedRO before going into the loop. That
        > should help to avoid the crash. At least it worked for the way I could
        > reproduce the crash.

        If you want me to try a patch out on 7.0c, I can.

        --
        [neil@fnx ~]# rm -f .signature
        [neil@fnx ~]# ls -l .signature
        ls: .signature: No such file or directory
        [neil@fnx ~]# exit
      • Neil Bird
        Around about 05/04/06 09:59, Neil Bird typed ... ... OK, this may help a tad. I have added auto-checkout to the original script. This is a snippet of what I
        Message 3 of 24 , Apr 5 2:59 AM
          Around about 05/04/06 09:59, Neil Bird typed ...
          > I'll trawl through it, and see if I can see anything. I don't think
          > it does though. However, it *does* parse the output of the command-line
          > SourceSafe commands somehow; they may go into a temp buffer.

          OK, this may help a tad. I have added auto-checkout to the original
          script. This is a snippet of what I currently have:

          let synid = synID(1,1,0)
          " Remember where we are (cursor can move to start of line upon load)
          let mark = line('.') . 'normal!' . virtcol('.') . '|'
          " Check out, getting latest
          exe g:scCommandPrefix.'Checkout'
          " Load latest before the edit happens
          e!
          " Go to where we were before the load
          exe mark
          " Work-around missing the syntax upon get
          if synid != 0
          syntax on
          endif


          Without that last bit, I found I lost syntax highlighting after the
          re-load. However, if I comment out the 'syntax on', the crash doesn't happen
          (although I get no syntax). I tried to reproduce the situation with a dummy
          version of the above, but haven't succeeded.

          --
          [neil@fnx ~]# rm -f .signature
          [neil@fnx ~]# ls -l .signature
          ls: .signature: No such file or directory
          [neil@fnx ~]# exit
        • Bram Moolenaar
          ... It s in snapshot 7.0c09. Only available as .zip file, CVS still doesn t work :-(. -- Engineers are always delighted to share wisdom, even in areas in
          Message 4 of 24 , Apr 5 6:03 AM
            Neil Bird wrote:

            > Around about 04/04/06 11:51, Bram Moolenaar typed ...
            > > Did you make sure the autocommand doesn't switch to another buffer,
            > > doesn't move the cursor, etc?
            >
            > I'll trawl through it, and see if I can see anything. I don't think it
            > does though. However, it *does* parse the output of the command-line
            > SourceSafe commands somehow; they may go into a temp buffer.
            >
            >
            > > I'll add a check for FileChangedRO before going into the loop. That
            > > should help to avoid the crash. At least it worked for the way I could
            > > reproduce the crash.
            >
            > If you want me to try a patch out on 7.0c, I can.

            It's in snapshot 7.0c09. Only available as .zip file, CVS still doesn't
            work :-(.

            --
            Engineers are always delighted to share wisdom, even in areas in which they
            have no experience whatsoever. Their logic provides them with inherent
            insight into any field of expertise. This can be a problem when dealing with
            the illogical people who believe that knowledge can only be derived through
            experience.
            (Scott Adams - The Dilbert principle)

            /// 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://www.ICCF.nl ///
          • Yakov Lerner
            ... I remember that you saif you don t plan cvs switches before end of vim7 beta; but here s my 5 cents: I saw several projects moving away from sf.net to
            Message 5 of 24 , Apr 5 7:37 AM
              On 4/5/06, Bram Moolenaar <Bram@...> wrote:

              > ... CVS still doesn't work :-(.

              I remember that you saif you don't plan cvs switches before end of vim7 beta;
              but here's my 5 cents:
              I saw several projects moving away from sf.net to savannah.gnu.org

              Yakov
            • Marvin Renich
              ... I have been unable to use cvs.sf.net for some time now, but ... since I saw mention of CVS troubles on this list a couple months back. (Of course, I am
              Message 6 of 24 , Apr 5 8:31 AM
                * Bram Moolenaar <Bram@...> [060405 09:12]:
                >
                > It's in snapshot 7.0c09. Only available as .zip file, CVS still doesn't
                > work :-(.
                >

                I have been unable to use cvs.sf.net for some time now, but
                :pserver:anonymous@...:80/cvsroot/vim has not failed
                since I saw mention of CVS troubles on this list a couple months back.
                (Of course, I am using anonymous, read-only access, and you need write
                access, but it is worth a try).

                Because the two server names refer to the same repository, you can
                simply change every CVS/Root file in your local copy to point to the
                other server. I did this by changing the top-most CVS/Root, then using

                find * -path '*/CVS/Root' -print0 | xargs -0 -n 1 cp CVS/Root

                to replace all the others. (Note "*" instead of "." as the first
                argument to find.)

                BTW, when you decide to investigate changing version control systems, I
                have a strong preference for subversion. I have not used git, but from
                what I have read, it do not believe that it would give any significant
                benefit over svn for this project, and the /usr/bin pollution does not
                appeal to me (which is one reason I haven't installed it to try it out).

                ...Marvin
              • James Vega
                ... Last I checked, Sf s site status said that anonymous CVS wasn t being synced with developer CVS. They had a pretty bad problem with their CVS server as
                Message 7 of 24 , Apr 5 9:01 AM
                  On Wed, Apr 05, 2006 at 11:31:51AM -0400, Marvin Renich wrote:
                  > * Bram Moolenaar <Bram@...> [060405 09:12]:
                  > >
                  > > It's in snapshot 7.0c09. Only available as .zip file, CVS still doesn't
                  > > work :-(.
                  > >
                  >
                  > I have been unable to use cvs.sf.net for some time now, but
                  > :pserver:anonymous@...:80/cvsroot/vim has not failed
                  > since I saw mention of CVS troubles on this list a couple months back.
                  > (Of course, I am using anonymous, read-only access, and you need write
                  > access, but it is worth a try).

                  Last I checked, Sf's site status said that anonymous CVS wasn't being
                  synced with developer CVS. They had a pretty bad problem with their CVS
                  server as you can see at <http://sourceforge.net/docs/A04>. Looks like
                  they do have a dev CVS server back up, though.

                  James
                  --
                  GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>
                • Marvin Renich
                  ... Thanks for enlightening me! ...Marvin
                  Message 8 of 24 , Apr 5 9:43 AM
                    * James Vega <jamessan@...> [060405 12:01]:
                    > On Wed, Apr 05, 2006 at 11:31:51AM -0400, Marvin Renich wrote:
                    > > * Bram Moolenaar <Bram@...> [060405 09:12]:
                    > > >
                    > > > It's in snapshot 7.0c09. Only available as .zip file, CVS still doesn't
                    > > > work :-(.
                    > > >
                    > >
                    > > I have been unable to use cvs.sf.net for some time now, but
                    > > :pserver:anonymous@...:80/cvsroot/vim has not failed
                    > > since I saw mention of CVS troubles on this list a couple months back.
                    > > (Of course, I am using anonymous, read-only access, and you need write
                    > > access, but it is worth a try).
                    >
                    > Last I checked, Sf's site status said that anonymous CVS wasn't being
                    > synced with developer CVS. They had a pretty bad problem with their CVS
                    > server as you can see at <http://sourceforge.net/docs/A04>. Looks like
                    > they do have a dev CVS server back up, though.
                    >
                    > James

                    Thanks for enlightening me!

                    ...Marvin
                  • Neil Bird
                    Around about 05/04/06 14:03, Bram Moolenaar typed ... ... That fixed it, thanks! Got a couple of ”E788: Not allowed to edit another buffer now” instead of
                    Message 9 of 24 , Apr 6 1:58 AM
                      Around about 05/04/06 14:03, Bram Moolenaar typed ...
                      >>> I'll add a check for FileChangedRO before going into the loop. That
                      >>> should help to avoid the crash. At least it worked for the way I could
                      >>> reproduce the crash.
                      >> If you want me to try a patch out on 7.0c, I can.
                      > It's in snapshot 7.0c09. Only available as .zip file, CVS still doesn't
                      > work :-(.

                      That fixed it, thanks! Got a couple of ”E788: Not allowed to edit another
                      buffer now” instead of a crash! Now I can fix the script.

                      --
                      [neil@fnx ~]# rm -f .signature
                      [neil@fnx ~]# ls -l .signature
                      ls: .signature: No such file or directory
                      [neil@fnx ~]# exit
                    • Neil Bird
                      Around about 06/04/06 09:58, Neil Bird typed ... ... OK, all is not as it seems. Although the above fix does prevent the crashes, with errors coming out, the
                      Message 10 of 24 , Apr 7 12:45 AM
                        Around about 06/04/06 09:58, Neil Bird typed ...
                        > Around about 05/04/06 14:03, Bram Moolenaar typed ...
                        >>>> I'll add a check for FileChangedRO before going into the loop. That
                        >>>> should help to avoid the crash. At least it worked for the way I could
                        >>>> reproduce the crash.
                        > That fixed it, thanks! Got a couple of ”E788: Not allowed to edit
                        > another buffer now” instead of a crash! Now I can fix the script.

                        OK, all is not as it seems. Although the above fix does prevent the
                        crashes, with errors coming out, the errors are for the two lines (not together):

                        e! " also tried just :e as the file's read-only
                        checktime


                        FileChangedRO says that the only permissible action is reloading the file,
                        which is effectively what both of the above do. Arguably I should use
                        :checktime both times (I added the :e! without knowing about :checktime).
                        Even then, :checktime says it doesn't do anything until the curernt autocmd
                        has finished.


                        So why do they both give the 'can't edit this buffer' error?

                        --
                        [neil@fnx ~]# rm -f .signature
                        [neil@fnx ~]# ls -l .signature
                        ls: .signature: No such file or directory
                        [neil@fnx ~]# exit
                      • Bram Moolenaar
                        ... The check for the current buffer to be locked was a bit too generic. I ll explicitly allow using :edit without an argument. -- hundred-and-one symptoms
                        Message 11 of 24 , Apr 7 3:35 AM
                          Neil Bird wrote:

                          > Around about 06/04/06 09:58, Neil Bird typed ...
                          > > Around about 05/04/06 14:03, Bram Moolenaar typed ...
                          > >>>> I'll add a check for FileChangedRO before going into the loop. That
                          > >>>> should help to avoid the crash. At least it worked for the way I could
                          > >>>> reproduce the crash.
                          > > That fixed it, thanks! Got a couple of ”E788: Not allowed to edit
                          > > another buffer now” instead of a crash! Now I can fix the script.
                          >
                          > OK, all is not as it seems. Although the above fix does prevent the
                          > crashes, with errors coming out, the errors are for the two lines (not together):
                          >
                          > e! " also tried just :e as the file's read-only
                          > checktime
                          >
                          >
                          > FileChangedRO says that the only permissible action is reloading the file,
                          > which is effectively what both of the above do. Arguably I should use
                          > :checktime both times (I added the :e! without knowing about :checktime).
                          > Even then, :checktime says it doesn't do anything until the curernt autocmd
                          > has finished.
                          >
                          >
                          > So why do they both give the 'can't edit this buffer' error?

                          The check for the current buffer to be locked was a bit too generic.
                          I'll explicitly allow using ":edit" without an argument.

                          --
                          hundred-and-one symptoms of being an internet addict:
                          18. Your wife drapes a blond wig over your monitor to remind you of what she
                          looks like.

                          /// 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://www.ICCF.nl ///
                        • Neil Bird
                          Around about 07/04/06 11:35, Bram Moolenaar typed ... ... What about :checktime ? Says it s postponed till after the autocmd, so should it be OK too? --
                          Message 12 of 24 , Apr 7 4:30 AM
                            Around about 07/04/06 11:35, Bram Moolenaar typed ...
                            > The check for the current buffer to be locked was a bit too generic.
                            > I'll explicitly allow using ":edit" without an argument.

                            What about :checktime ? Says it's postponed till after the autocmd, so
                            should it be OK too?

                            --
                            [neil@fnx ~]# rm -f .signature
                            [neil@fnx ~]# ls -l .signature
                            ls: .signature: No such file or directory
                            [neil@fnx ~]# exit
                          • Bram Moolenaar
                            ... Hmm, it seems so. I ll add an exception for that too. -- hundred-and-one symptoms of being an internet addict: 27. You refer to your age as 3.x. /// Bram
                            Message 13 of 24 , Apr 7 5:56 AM
                              Neil Bird wrote:

                              > Around about 07/04/06 11:35, Bram Moolenaar typed ...
                              > > The check for the current buffer to be locked was a bit too generic.
                              > > I'll explicitly allow using ":edit" without an argument.
                              >
                              > What about :checktime ? Says it's postponed till after the autocmd, so
                              > should it be OK too?

                              Hmm, it seems so. I'll add an exception for that too.

                              --
                              hundred-and-one symptoms of being an internet addict:
                              27. You refer to your age as 3.x.

                              /// 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://www.ICCF.nl ///
                            • Neil Bird
                              Around about 07/04/06 13:56, Bram Moolenaar typed ... ... Well, I no longer get the two errors about not being able to edit, but I m back to crashes :-( [vim
                              Message 14 of 24 , Apr 19 1:38 AM
                                Around about 07/04/06 13:56, Bram Moolenaar typed ...
                                >>> The check for the current buffer to be locked was a bit too generic.
                                >>> I'll explicitly allow using ":edit" without an argument.
                                >> What about :checktime ? Says it's postponed till after the autocmd, so
                                >> should it be OK too?
                                > Hmm, it seems so. I'll add an exception for that too.

                                Well, I no longer get the two errors about not being able to edit, but I'm
                                back to crashes :-( [vim 7.0e]

                                The original problem (crashing when checking out a file during diff mode
                                'dp') seems to have actually been fixed, or, at least, it now hasn't crashed
                                for me.

                                However, the newer instance (a checkout triggered by 'z=' spell checking)
                                has gotten worse. I get an error (sometmies SEGV, sometimes ABRT) and then
                                vim hangs:

                                *** glibc detected *** free(): invalid next size (fast): 0x09926868 ***
                                Vim: Caught deadly signal ABRT
                                Vim: preserving files...


                                ^C doesn't get out of that, I have to 'kill -9' it. Annoyingly, it doesn't
                                crash (per se) running under ddd. I did once get:

                                E341: Internal error: lalloc(0, )

                                ... but it seemed to recover. It /does/, however, insert a smattering of
                                random text instead of the selected word (from z=), seemingly as small bit of
                                the current file, only a few characters [but not the same length as the spell
                                word].


                                This is better for me, as it was the diff mode thing I was hitting a lot,
                                and I can avoid the spelling one, but it's still worrying ...

                                If I come up with any more info., I'll let you know.

                                --
                                [neil@fnx ~]# rm -f .signature
                                [neil@fnx ~]# ls -l .signature
                                ls: .signature: No such file or directory
                                [neil@fnx ~]# exit
                              • Neil Bird
                                Around about 19/04/06 09:38, Neil Bird typed ... ... OK, spoke too soon, I seem to be able to subtly change the behaviour by which spell option I select. I d
                                Message 15 of 24 , Apr 19 1:45 AM
                                  Around about 19/04/06 09:38, Neil Bird typed ...
                                  > If I come up with any more info., I'll let you know.

                                  OK, spoke too soon, I seem to be able to subtly change the behaviour by
                                  which spell option I select. I'd always been selecting '1', the first, to get
                                  the crashes before; selecting others seems to behave 'better'. I just did 1
                                  again and caught a crash in I think the same place as before (I'll check in a
                                  sec.):

                                  *** glibc detected *** free(): invalid next size (fast): 0x0a5e7368 ***
                                  Program received signal SIGABRT, Aborted.

                                  #0 0xb7f8d402 in __kernel_vsyscall ()
                                  #1 0x009597d5 in raise ()
                                  #2 0x0095b149 in abort ()
                                  #3 0x0098d40a in __libc_message ()
                                  #4 0x00993b3f in _int_free ()
                                  #5 0x00993eba in free ()
                                  #6 0x08127476 in vim_free (x=0xa5e7368) at misc2.c:1463
                                  #7 0x0810edd2 in ml_flush_line (buf=0xa271bd0) at memline.c:3096
                                  #8 0x0810d56c in ml_get_buf (buf=0xa271bd0, lnum=1, will_change=0) at
                                  memline.c:2065
                                  #9 0x080e38f2 in move_lines (frombuf=0xa271bd0, tobuf=0xa590910) at fileio.c:6139
                                  #10 0x080e421a in buf_reload (buf=0xa271bd0, orig_mode=33133) at fileio.c:6494
                                  #11 0x080e409a in buf_check_timestamp (buf=0xa271bd0, focus=0) at fileio.c:6419
                                  #12 0x080e3831 in check_timestamps (focus=0) at fileio.c:6095
                                  #13 0x080fd5de in main_loop (cmdwin=0, noexmode=0) at main.c:993
                                  #14 0x080fd4cb in main (argc=4, argv=0xbf88cec4) at main.c:930


                                  vim_free(x)
                                  void *x;
                                  {
                                  if (x != NULL && !really_exiting)
                                  {
                                  #ifdef MEM_PROFILE
                                  mem_pre_free(&x);
                                  #endif
                                  free(x); <-- here --|
                                  }
                                  }

                                  x is 0xa5e7368 FWIW.


                                  Would this MEM_PROFILE be of help?

                                  --
                                  [neil@fnx ~]# rm -f .signature
                                  [neil@fnx ~]# ls -l .signature
                                  ls: .signature: No such file or directory
                                  [neil@fnx ~]# exit
                                • Bram Moolenaar
                                  ... Apparently your FileChangedRO autocommand does something nasty. I suspect we need to detect that nastyness and disallow it. Any idea what the nasty bit
                                  Message 16 of 24 , Apr 19 4:07 AM
                                    Neil Bird wrote:

                                    > Around about 07/04/06 13:56, Bram Moolenaar typed ...
                                    > >>> The check for the current buffer to be locked was a bit too generic.
                                    > >>> I'll explicitly allow using ":edit" without an argument.
                                    > >> What about :checktime ? Says it's postponed till after the autocmd, so
                                    > >> should it be OK too?
                                    > > Hmm, it seems so. I'll add an exception for that too.
                                    >
                                    > Well, I no longer get the two errors about not being able to edit, but I'm
                                    > back to crashes :-( [vim 7.0e]
                                    >
                                    > The original problem (crashing when checking out a file during diff mode
                                    > 'dp') seems to have actually been fixed, or, at least, it now hasn't crashed
                                    > for me.
                                    >
                                    > However, the newer instance (a checkout triggered by 'z=' spell checking)
                                    > has gotten worse. I get an error (sometmies SEGV, sometimes ABRT) and then
                                    > vim hangs:
                                    >
                                    > *** glibc detected *** free(): invalid next size (fast): 0x09926868 ***
                                    > Vim: Caught deadly signal ABRT
                                    > Vim: preserving files...

                                    Apparently your FileChangedRO autocommand does something nasty. I
                                    suspect we need to detect that nastyness and disallow it. Any idea what
                                    the nasty bit could be?

                                    After some pointers go wrong anything can happen, thus how it crashes
                                    exactly is not interesting. It could help to use a library that forbids
                                    access to freed memory, like efence. Then the error is detected much
                                    earlier and a stack trace may provide more useful info.

                                    --
                                    "Hit any key to continue" does _not_ mean you can hit the on/off button!

                                    /// 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://www.ICCF.nl ///
                                  • Neil Bird
                                    Around about 19/04/06 12:07, Bram Moolenaar typed ... ... I tried making a cut down fake version, but that always worked. It s essentially doing a couple of
                                    Message 17 of 24 , Apr 19 5:09 AM
                                      Around about 19/04/06 12:07, Bram Moolenaar typed ...
                                      > Apparently your FileChangedRO autocommand does something nasty. I
                                      > suspect we need to detect that nastyness and disallow it. Any idea what
                                      > the nasty bit could be?

                                      I tried making a cut down fake version, but that always worked. It's
                                      essentially doing a couple of system() [vim] calls, one's a 'cat' of a config
                                      file, the next is the actual remote sourcesafe checkout command (via rsh), of
                                      each of which it parses the output.

                                      Then it does a :edit to reload the buffer and a 'syntax on'. ISTRT if I
                                      comment out the :syntax on' it stops crashing, but I then get a file with no
                                      syntax highlighting (even though it was on before). Maybe that in itself is
                                      the issue.


                                      > After some pointers go wrong anything can happen, thus how it crashes
                                      > exactly is not interesting. It could help to use a library that forbids
                                      > access to freed memory, like efence. Then the error is detected much
                                      > earlier and a stack trace may provide more useful info.

                                      ef is not reporting anything [except its banner], although it does make it
                                      not crash fatally [locked after crash], albeit with the corrupted text as a
                                      spell replacement. Any other recommended tools?

                                      --
                                      [neil@fnx ~]# rm -f .signature
                                      [neil@fnx ~]# ls -l .signature
                                      ls: .signature: No such file or directory
                                      [neil@fnx ~]# exit
                                    • Giuseppe Bilotta
                                      ... Can Vim be run with Valgrind? -- Giuseppe Oblomov Bilotta I weep for our generation -- Charlie Brown
                                      Message 18 of 24 , Apr 19 5:38 AM
                                        On Wed, 19 Apr 2006 13:07:12 +0200, Bram Moolenaar wrote:

                                        > After some pointers go wrong anything can happen, thus how it crashes
                                        > exactly is not interesting. It could help to use a library that forbids
                                        > access to freed memory, like efence. Then the error is detected much
                                        > earlier and a stack trace may provide more useful info.

                                        Can Vim be run with Valgrind?

                                        --
                                        Giuseppe "Oblomov" Bilotta

                                        "I weep for our generation" -- Charlie Brown
                                      • Bram Moolenaar
                                        ... Main issue is: Do you open another buffer or window? I guess the basic sequence is: - you do z= and select a suggestion, this is to be inserted - your
                                        Message 19 of 24 , Apr 19 12:03 PM
                                          Neil Bird wrote:

                                          > Around about 19/04/06 12:07, Bram Moolenaar typed ...
                                          > > Apparently your FileChangedRO autocommand does something nasty. I
                                          > > suspect we need to detect that nastyness and disallow it. Any idea what
                                          > > the nasty bit could be?
                                          >
                                          > I tried making a cut down fake version, but that always worked. It's
                                          > essentially doing a couple of system() [vim] calls, one's a 'cat' of a config
                                          > file, the next is the actual remote sourcesafe checkout command (via rsh), of
                                          > each of which it parses the output.
                                          >
                                          > Then it does a :edit to reload the buffer and a 'syntax on'. ISTRT if I
                                          > comment out the :syntax on' it stops crashing, but I then get a file with no
                                          > syntax highlighting (even though it was on before). Maybe that in itself is
                                          > the issue.

                                          Main issue is: Do you open another buffer or window?

                                          I guess the basic sequence is:
                                          - you do "z=" and select a suggestion, this is to be inserted
                                          - your file is RO, thus the FileChangedRO autocmd is triggered
                                          - your FileChangedRO autocmd uses sourcesafe to get the file
                                          Hmm, does this then trigger the timestamp check and
                                          trigger a FileChangedShell autocmd?
                                          - your FileChangedRO autocmd reloads the file

                                          > > After some pointers go wrong anything can happen, thus how it crashes
                                          > > exactly is not interesting. It could help to use a library that forbids
                                          > > access to freed memory, like efence. Then the error is detected much
                                          > > earlier and a stack trace may provide more useful info.
                                          >
                                          > ef is not reporting anything [except its banner], although it does make it
                                          > not crash fatally [locked after crash], albeit with the corrupted text as a
                                          > spell replacement. Any other recommended tools?

                                          Efence should make your application crash as soon as it accesses memory
                                          that it shouldn't access.

                                          --
                                          hundred-and-one symptoms of being an internet addict:
                                          169. You hire a housekeeper for your home page.

                                          /// 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://www.ICCF.nl ///
                                        • Neil Bird
                                          Around about 19/04/06 13:38, Giuseppe Bilotta typed ... ... Tried that; couldn t see the wood for the trees :-( -- [neil@fnx ~]# rm -f .signature [neil@fnx
                                          Message 20 of 24 , Apr 21 1:09 AM
                                            Around about 19/04/06 13:38, Giuseppe Bilotta typed ...
                                            > Can Vim be run with Valgrind?

                                            Tried that; couldn't see the wood for the trees :-(

                                            --
                                            [neil@fnx ~]# rm -f .signature
                                            [neil@fnx ~]# ls -l .signature
                                            ls: .signature: No such file or directory
                                            [neil@fnx ~]# exit
                                          • Neil Bird
                                            Around about 19/04/06 20:03, Bram Moolenaar typed ... ... I don t believe so. Apart from some tricky indirection (the srcctl plugin has a generic set up, then
                                            Message 21 of 24 , Apr 21 1:16 AM
                                              Around about 19/04/06 20:03, Bram Moolenaar typed ...
                                              > Main issue is: Do you open another buffer or window?

                                              I don't believe so. Apart from some tricky indirection (the srcctl plugin
                                              has a generic set up, then calls the relevant real script functions depending
                                              upon the SCM S/W being used, SourceSafe in my case), the sequence is pretty
                                              much as you describe below.

                                              The process does involve at least 2, maybe three system() calls [one 'cat'
                                              of the config. file, one to deduce the status of the file in an initial
                                              check-out attempt, and a potential third if this fails or requires
                                              interaction: the script parses the output and if a question is asked (say,
                                              "are you sure?"), converts this into a vim dialogue [is *that* the issue?
                                              interactivity during the autocmd?].

                                              I then have a bit that forcibly reloads the file (otherwise the edit that
                                              triggered the autocmd happens in the to-be-forgotten read-only version of the
                                              file), then finally the 'syntax on' which for some reason is required to make
                                              the freshly loaded file have syntax highlighting.


                                              > I guess the basic sequence is:
                                              > - you do "z=" and select a suggestion, this is to be inserted
                                              > - your file is RO, thus the FileChangedRO autocmd is triggered
                                              > - your FileChangedRO autocmd uses sourcesafe to get the file
                                              > Hmm, does this then trigger the timestamp check and
                                              > trigger a FileChangedShell autocmd?
                                              > - your FileChangedRO autocmd reloads the file

                                              As above; I don't know about the FileChangedShell autocmd; I can set a
                                              dummy one up to see if it's happening if it'll help.


                                              > Efence should make your application crash as soon as it accesses memory
                                              > that it shouldn't access.

                                              Well, as I said, it made it /not/ crash instead :-/

                                              --
                                              [neil@fnx ~]# rm -f .signature
                                              [neil@fnx ~]# ls -l .signature
                                              ls: .signature: No such file or directory
                                              [neil@fnx ~]# exit
                                            • Neil Bird
                                              Around about 21/04/06 09:16, Neil Bird typed ... ... There s no FileChangedShell autocmd to be triggered. The script /does/ temporarily set autoread around
                                              Message 22 of 24 , Apr 21 1:58 AM
                                                Around about 21/04/06 09:16, Neil Bird typed ...
                                                >> I guess the basic sequence is:
                                                >> - you do "z=" and select a suggestion, this is to be inserted
                                                >> - your file is RO, thus the FileChangedRO autocmd is triggered
                                                >> - your FileChangedRO autocmd uses sourcesafe to get the file
                                                >> Hmm, does this then trigger the timestamp check and
                                                >> trigger a FileChangedShell autocmd?
                                                >> - your FileChangedRO autocmd reloads the file

                                                There's no FileChangedShell autocmd to be triggered. The script /does/
                                                temporarily set autoread around the system() call that may check out the file,
                                                and also calls 'checktime' before resetting it, but that doesn't actually
                                                achieve anything (the checktime its deferred?) as you then get a 'file has
                                                changed, reload?' prompt a bit later. My manually loading the file (:e)
                                                prevents this; maybe that's confusing something. Certainly, I don't get a
                                                crash if don't manually load the file (as well as not crashing if I *do* load
                                                the file, but don't set syntax).

                                                --
                                                [neil@fnx ~]# rm -f .signature
                                                [neil@fnx ~]# ls -l .signature
                                                ls: .signature: No such file or directory
                                                [neil@fnx ~]# exit
                                              • Bram Moolenaar
                                                ... I still don t see a hint about what causes the problem. Note that I have added a few extra checks in the code that you mentioned in the previous stack
                                                Message 23 of 24 , Apr 21 4:27 AM
                                                  Neil Bird wrote:

                                                  > Around about 19/04/06 20:03, Bram Moolenaar typed ...
                                                  > > Main issue is: Do you open another buffer or window?
                                                  >
                                                  > I don't believe so. Apart from some tricky indirection (the srcctl
                                                  > plugin has a generic set up, then calls the relevant real script
                                                  > functions depending upon the SCM S/W being used, SourceSafe in my
                                                  > case), the sequence is pretty much as you describe below.
                                                  >
                                                  > The process does involve at least 2, maybe three system() calls [one 'cat'
                                                  > of the config. file, one to deduce the status of the file in an initial
                                                  > check-out attempt, and a potential third if this fails or requires
                                                  > interaction: the script parses the output and if a question is asked (say,
                                                  > "are you sure?"), converts this into a vim dialogue [is *that* the issue?
                                                  > interactivity during the autocmd?].
                                                  >
                                                  > I then have a bit that forcibly reloads the file (otherwise the edit that
                                                  > triggered the autocmd happens in the to-be-forgotten read-only version of the
                                                  > file), then finally the 'syntax on' which for some reason is required to make
                                                  > the freshly loaded file have syntax highlighting.
                                                  >
                                                  >
                                                  > > I guess the basic sequence is:
                                                  > > - you do "z=" and select a suggestion, this is to be inserted
                                                  > > - your file is RO, thus the FileChangedRO autocmd is triggered
                                                  > > - your FileChangedRO autocmd uses sourcesafe to get the file
                                                  > > Hmm, does this then trigger the timestamp check and
                                                  > > trigger a FileChangedShell autocmd?
                                                  > > - your FileChangedRO autocmd reloads the file
                                                  >
                                                  > As above; I don't know about the FileChangedShell autocmd; I can set a
                                                  > dummy one up to see if it's happening if it'll help.

                                                  I still don't see a hint about what causes the problem.

                                                  Note that I have added a few extra checks in the code that you mentioned
                                                  in the previous stack trace. You could try the latest snapshot if it
                                                  works any better.

                                                  --
                                                  "The amigos also appear to be guilty of not citing the work of others who had
                                                  gone before them. Even worse, they have a chapter about modeling time and
                                                  space without making a single reference to Star Trek!"
                                                  (Scott Ambler, reviewing the UML User Guide)

                                                  /// 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://www.ICCF.nl ///
                                                Your message has been successfully submitted and would be delivered to recipients shortly.