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

Re: VIM-Crash after "Hit Enter ...": logged with verbose=20

Expand Messages
  • Benji Fisher
    ... What version of Microsoft are you using? ... I do not think in essence is enough for me to even try reproducing the bug. Have you tried removing the
    Message 1 of 11 , Jul 31, 2004
    • 0 Attachment
      On Sun, Aug 01, 2004 at 12:59:17AM +0000, Suresh Govindachar wrote:
      > Hello,
      >
      > Attached is a "verbose=20" log of a VIM crash.
      >
      > 1) BACKGROUND: WHAT THE USER SEES:
      >
      > When user responds with <Enter> to the message:
      >
      > Hit Enter or type command to continue
      >
      > VIM crashes -- Microsoft says
      > "Illegal operation and will be shut down ..."

      What version of Microsoft are you using?

      > 2) ABOUT THE COMMAND ISSUED BY THE USER:
      >
      > The user issued the command:
      > :perl tms_w_do_this('d');
      >
      > In essence, the subroutine tms_w_do_this looks like:
      >
      > sub tms_w_do_this
      > {
      > <code>
      >
      > VIM::DoCommand("echoerr 'Watch-out for an unscheduled VIM-CRASH!!!'"):
      > return 1;
      > }

      I do not think "in essence" is enough for me to even try
      reproducing the bug. Have you tried removing the body of the subroutine
      except for the VIM::DoCommand line (and the return line)? Can you give
      instructions, for someone who does not normally use Perl, on how to
      define the subroutine and make it visible to vim?

      > The user does see the line: "Watch-out for an unscheduled
      > VIM-CRASH!!!" just above the "Hit Enter or type command to
      > continue" message.
      >
      > 3) THE VERBOSE=20 LOG WAS MADE BY ISSUING:
      >
      > the command :silent call BugRecorder() where:
      >
      > function! BugRecoreder()
      >
      > echo "about to begin ..."
      > set nomore
      > :redir! >> fooey
      > echo "BEGIN"
      > set verbose=20
      > perl tms_w_do_this('d');
      > echo "DONE"
      > set verbose=0
      > echo "done again"
      > :redir END
      > set more
      > echo "all done!"
      >
      > endfunction
      >
      > 4) THE CRASH ALSO HAPPENS WHEN THE SUBROUTINE
      > is invoked with the mapping (all in one line):
      >
      > nmap <buffer> <LocalLeader>d :perl VIM::Msg("Watch out for a VIM CRASH!:".tms_w_do_this('d').",");<CR>
      >
      > The message "Watch out for a VIM CRASH!:1," (the
      > 1 is the return value of the subroutine) shows
      > up as expected above the "Hit Enter or ..." message.
      >
      > 5) The crash does not happen always. It
      > happens about in 1 out of 2 to 3 calls.
      >
      > I have been working on this all day, and
      > can't think of anything else to do.
      >
      > By the way: When I set verbose to 20 and call
      > the subroutine by hand (instead of calling with
      > the wrapper function), there seems to be much
      > more messages than what has been captured in the
      > log file. Does it just seem like there are more
      > messages, or does the wrapper function miss some
      > messages?
      >
      > I hope this can be fixed without me having to
      > make a debug build of VIM.
      >
      > Thanks,
      >
      > --Suresh

      I will try to edit out some parts of the log that seem harmless to
      me. Also, I will remove some "blank" lines.

      > ______________________________________________
      > BEGIN
      > line 7: perl tms_w_do_this('d');
      > line 7: let b:tms_fooey = fnamemodify('d:\tms\tms\inbox\index.idx', ':p')
      > line 7: let b:tms_fooey = fnamemodify('d:\tms\tms\inbox\ViMozilla.eml', ':p')
      > line 7: let b:tms_fooey = fnamemodify('d:\tms\tms\inbox\index.idx', ':p')
      > line 7: drop d:\tms\tms\inbox\index.idx

      That seems a little round-about, and it must have come from all the
      <code> that you suppressed. Ditto for the following lines, which seem
      to involve entering and exiting some buffers and windows.

      > Executing WinEnter Auto commands for "*"
      > autocommand if !exists("w:sortdirection") | call s:EditDir() | endif
      [harmless]
      > function <SNR>52_EditDir returning #0
      > continuing in WinEnter Auto commands for "*"
      > line 0: endif
      >
      > Executing BufEnter Auto commands for "*"
      > autocommand call s:EditDir()
      [still harmless]
      > function <SNR>52_EditDir returning #0
      >
      > continuing in BufEnter Auto commands for "*"

      Back to the mysterious <code> in tms_w_do_this(), it seems:

      > line 7: normal gg
      > line 7: / ViMozilla.eml\s*$
      > line 7: nohls
      > line 7: let b:tms_fooey = fnamemodify('d:\tms\tms\inbox\ViMozilla.eml', ':p')
      > line 7: drop d:\tms\tms\inbox\index.idx
      > line 7: update
      > "d:\tms\tms\inbox\index.idx" 5L, 1147C written
      > line 7: silent! bw! d:\tms\tms\inbox\ViMozilla.eml

      I might remove the silent! for debugging purposes.

      > Executing BufUnload Auto commands for "*"
      > autocommand call s:CVSVimDiffRestore(expand("<abuf>"))
      [looks harmless, but have you tried removing this plugin?]
      > function <SNR>28_CVSVimDiffRestore returning #0
      >
      > continuing in BufUnload Auto commands for "*"
      >
      > Executing BufDelete Auto commands for "*"
      > autocommand call <SID>BMRemove()
      > line 0: call <SID>BMRemove()
      > calling function <SNR>10_BMRemove()
      [looks harmless]
      > function <SNR>10_BMRemove returning #0
      >
      > continuing in BufDelete Auto commands for "*"

      Back to the mysterious <code> in tms_w_do_this(), it seems:

      > line 7: let foo = delete("d:/tms/tms/inbox/ViMozilla.eml")
      > line 7: echoerr 'DONE: this line is needed to help catch a bug'
      > Error detected while processing function BugRecoreder:
      > line 7:
      > DONE: this line is needed to help catch a bug
      > line 7: echohl None
      > line 7: echoerr 'Watch-out for an unscheduled VIM-CRASH!!!'
      > Watch-out for an unscheduled VIM-CRASH!!!
      > line 7: echohl None

      Well, that line is done, and we move on to the end of the
      BugRecoreder() function:

      > line 8: echo "DONE"
      > DONE
      > line 9: set verbose=0
      > done again

      HTH --Benji Fisher
    • Suresh Govindachar
      In essence, the problem I reported on: Sun, 1 Aug 2004 00:59:17 +0000 was: After executing an embedded perl subroutine and returning SUCCESSFULLY from it, the
      Message 2 of 11 , Aug 9, 2004
      • 0 Attachment
        In essence, the problem I reported on:
        Sun, 1 Aug 2004 00:59:17 +0000 was:

        After executing an embedded perl subroutine and returning
        SUCCESSFULLY from it, the gvim session would crash every
        once in about 3 times. (Windows 98).

        I made the following changes, and haven't had a crash:

        Changed _vimrc by adding these three lets:

        let no_buffers_menu = 1
        let did_install_default_menus = 1
        let did_install_syntax_menu = 1

        and changed guioptins from just 'a' to:

        set guioptions=acM

        Then I unregistered gvim. Crashes still happened.

        Then in the perl code, changed all the buffwipeout
        commands (:bw) to bufunload (:bun).

        The crashes stopped (four days of use).

        Than I registered VIM (continuing to use bun instead of bw)

        No crashes as yet (one day of use).

        Anyway, I have tested the plugin extensively on Windows 98
        and briefly on Linux. It works. I expect to release it
        later today. The release version will have :bw in it;
        however, users can do "let g:tms_do_not_bw_in_perl = 1" to
        change all the :bw used in perl code to :bun.

        --Suresh
      • Benji Fisher
        ... To complete the experiment, I think you should try the plugin without g:tms_do_not_bw_in_perl defined, watch it crash, define g:tms_do_not_bw_in_perl , and
        Message 3 of 11 , Aug 10, 2004
        • 0 Attachment
          On Mon, Aug 09, 2004 at 10:11:11PM +0000, Suresh Govindachar wrote:
          > In essence, the problem I reported on:
          > Sun, 1 Aug 2004 00:59:17 +0000 was:
          >
          > After executing an embedded perl subroutine and returning
          > SUCCESSFULLY from it, the gvim session would crash every
          > once in about 3 times. (Windows 98).
          >
          > I made the following changes, and haven't had a crash:
          >
          > Changed _vimrc by adding these three lets:
          >
          > let no_buffers_menu = 1
          > let did_install_default_menus = 1
          > let did_install_syntax_menu = 1
          >
          > and changed guioptins from just 'a' to:
          >
          > set guioptions=acM
          >
          > Then I unregistered gvim. Crashes still happened.
          >
          > Then in the perl code, changed all the buffwipeout
          > commands (:bw) to bufunload (:bun).
          >
          > The crashes stopped (four days of use).
          >
          > Than I registered VIM (continuing to use bun instead of bw)
          >
          > No crashes as yet (one day of use).
          >
          > Anyway, I have tested the plugin extensively on Windows 98
          > and briefly on Linux. It works. I expect to release it
          > later today. The release version will have :bw in it;
          > however, users can do "let g:tms_do_not_bw_in_perl = 1" to
          > change all the :bw used in perl code to :bun.

          To complete the experiment, I think you should try the plugin
          without g:tms_do_not_bw_in_perl defined, watch it crash, define
          g:tms_do_not_bw_in_perl , and watch it not crash. Do the changes to the
          vimrc file matter? (I assume they are still there, but maybe not?)

          HTH --Benji Fisher
        • Suresh Govindachar
          ... Right about what needs to be done to complete the experiment. Undefining g:tms_do_not_bw_in_perl resulted in a crash; defining it did not. Also, removing
          Message 4 of 11 , Aug 12, 2004
          • 0 Attachment
            Benji Fisher sent on Tue, 10 Aug 2004 08:53:13 -0400:
            > On Mon, Aug 09, 2004 at 10:11:11PM +0000, Suresh Govindachar wrote:
            > > In essence, the problem I reported on:
            > > Sun, 1 Aug 2004 00:59:17 +0000 was:
            > >
            > > After executing an embedded perl subroutine and
            > > returning SUCCESSFULLY from it, the gvim session would
            > > crash every once in about 3 times. (Windows 98).
            > >
            > > I made the following changes, and haven't had a crash:
            > >
            > > Changed _vimrc by adding these three lets:
            > >
            > > let no_buffers_menu = 1
            > > let did_install_default_menus = 1
            > > let did_install_syntax_menu = 1
            > >
            > > and changed guioptins from just 'a' to:
            > >
            > > set guioptions=acM
            > >
            > > Then I unregistered gvim. Crashes still happened.
            > >
            > > Then in the perl code, changed all the buffwipeout
            > > commands (:bw) to bufunload (:bun).
            > >
            > > The crashes stopped (four days of use).
            > >
            > > Than I registered VIM (continuing to use bun instead of bw)
            > >
            > > No crashes as yet (one day of use).
            > >
            > > Anyway, I have tested the plugin extensively on Windows
            > > 98 and briefly on Linux. It works. I expect to release
            > > it later today. The release version will have :bw in
            > > it; however, users can do "let g:tms_do_not_bw_in_perl =
            > > 1" to change all the :bw used in perl code to :bun.
            >
            > To complete the experiment, I think you should try the
            > plugin without g:tms_do_not_bw_in_perl defined, watch it
            > crash, define g:tms_do_not_bw_in_perl , and watch it not
            > crash. Do the changes to the vimrc file matter? (I
            > assume they are still there, but maybe not?)

            Right about what needs to be done to complete the
            experiment.

            Undefining g:tms_do_not_bw_in_perl resulted in a crash;
            defining it did not.

            Also, removing the 3 lets (for no_buffers_menu,
            did_install_default_menus and did_install_syntax_menu)
            and setting guioptions to just 'a' while having
            g:tms_do_not_bw_in_perl set to 1 did not result in
            a crash (tested this for a short time only).

            Anyway, I am back to the state of having the 3 lets
            and having guioptions to acM and doing bun's instead
            of bw's in perl.

            --Suresh
          • Bram Moolenaar
            ... You appear to describe the problem in your own words. For reproducing and understanding the problem it is important that you quote everything literally.
            Message 5 of 11 , Aug 29, 2004
            • 0 Attachment
              Suresh Govindachar wrote:

              > Attached is a "verbose=20" log of a VIM crash.
              >
              > 1) BACKGROUND: WHAT THE USER SEES:
              >
              > When user responds with <Enter> to the message:
              >
              > Hit Enter or type command to continue
              >
              > VIM crashes -- Microsoft says
              > "Illegal operation and will be shut down ..."

              You appear to describe the problem in your own words. For reproducing
              and understanding the problem it is important that you quote everything
              literally.

              > 2) ABOUT THE COMMAND ISSUED BY THE USER:
              >
              > The user issued the command:
              > :perl tms_w_do_this('d');
              >
              > In essence, the subroutine tms_w_do_this looks like:
              >
              > sub tms_w_do_this
              > {
              > <code>
              >
              > VIM::DoCommand("echoerr 'Watch-out for an unscheduled VIM-CRASH!!!'"):
              > return 1;
              > }

              What Vim commands do I use to define this subroutine? Without that info
              I can't reproduce the problem.

              Please find the shortest example that causes the problem. "<code>"
              doesn't work, you must put something there that does work to be able to
              reproduce the problem.

              --
              hundred-and-one symptoms of being an internet addict:
              216. Your pet rock leaves home.

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
              \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
            • Suresh Govindachar
              ... I understand the need for a crash-report to have the shortest possible reproducible example. I have tried, but have been unable to create a simple
              Message 6 of 11 , Aug 29, 2004
              • 0 Attachment
                Bram Moolenaar Sent: 29 Aug 2004 22:02:29 +0200:

                > What Vim commands do I use to define this subroutine?
                > Without that info I can't reproduce the problem.
                >
                > Please find the shortest example that causes the problem.
                > "<code>" doesn't work, you must put something there that
                > does work to be able to reproduce the problem.

                I understand the need for a crash-report to have the
                shortest possible reproducible example. I have tried, but
                have been unable to create a simple example.

                However, I can provide the original code and the steps to go
                through. When I go through those steps, gvim crashes.

                First, here's a recap:

                Gvim is released 6.3, Big version with GUI, compiled
                Jun 7 2004 14:20:56. OS is Windows 98.

                After executing an embedded perl subroutine and returning
                SUCCESSFULLY from it, the gvim session crashes every once
                in about 3 times. The crash happens after the perl-code
                does its thing properly and returns control of gvim to the
                manual user.

                Crash happens even after doing the following in vimrc:

                let no_buffers_menu = 1
                let did_install_default_menus = 1
                let did_install_syntax_menu = 1
                set guioptions=a

                and unregistering gvim.

                But crashes do not happen if, in the perl code, all the
                all the buffwipeout commands (:bw) are changed to
                bufunload (:bun).

                Finally, when :bun is used instead of :bw, crashes do not
                happen even if gvim is registered, guioptions is set to
                acM, and the preceding three lets are not done.

                Here's how to reproduce the crash.

                1) Plugin is http://www.vim.org/scripts/script.php?script_id=1052

                2) In creating vimfiles/mail/_tmsrc, the only critical items
                for the test will be the directories

                3) Create a sub-folder under dir_mail_home (say,
                dir_mail_home is d:/tms and this sub-folder is atest).
                Then copy some (any 10 or more) .eml files into
                d:/tms/atest. .eml files can be copied, for example, by
                selecting them in Outlook and draging and dropping.

                4) The file vimfiles/mail/tms.vim defines some maps.
                The maps involved in this test are: \i, \o, and \d.

                5) Do \i; a prompt will come up; respond atest at the
                prompt. This will create the files index.raw and
                index.idx inside the folder d:/tms/atest.

                6) Open d:/tms/atest/index.idx. Pick a line (other than the
                header and border lines) and do \o. A new window will
                appear with a .eml file.

                7) Then do some scrolling, unfolding etc. commands in the
                .eml file. Then do \d, while bracing yourself for a
                crash.

                8) The buffer will be wiped out and replaced by a new .eml
                buffer (corresponding to the "next line" in the
                index.idx file). Repeat 7 in this buffer.

                9) After a few repeats of 8, Vim might crash.

                10) If vim does crash then do the following: In
                vimfiles/plugin/tms.vim expose the line:
                let g:tms_do_not_bw_in_perl = 1
                This will change all the :bw in the embedded perl code
                to :bun, and vim won't crash.

                11) If you want to actually try out the plugin, be
                sure to have valid entries for the mail servers
                in the _tmsrc file; and to set up the passwords
                (besides help tms, see vimfiles/mail/release_notes).

                If you do go ahead with the test, let me know the results
                and any other comments.

                By the way, I have been using tms (with
                tms_do_not_bw_in_perl let to 1) -- and am very happy with
                it. Since the last release of tms, I have added filtering
                capability: now, after downloading emails:

                - emails are sorted into sub-folders of dir_mail_home
                based on filtering rules
                - a quickfix tags (or "errors.err") file is created based
                on where the newly arrived files are.
                - the cfile command is issued on the tags file
                - User can then use quickfix commands to visit the folders
                with newly arrived emails.

                A request: I looked at the description of your upcoming
                tutorial and noticed mention of using VIM for email. Please
                consider mentioning the tms.vim plugin to send, receive and
                organize email from within VIM!

                Thanks,

                --Suresh
              • Bram Moolenaar
                ... This is too complicated to try out. I rather guess. ... Make sure you use the right DLL for Perl. That should be perl58.dll. More precisely: ActivePerl
                Message 7 of 11 , Aug 30, 2004
                • 0 Attachment
                  Suresh Govindachar wrote:

                  > Bram Moolenaar Sent: 29 Aug 2004 22:02:29 +0200:
                  >
                  > > What Vim commands do I use to define this subroutine?
                  > > Without that info I can't reproduce the problem.
                  > >
                  > > Please find the shortest example that causes the problem.
                  > > "<code>" doesn't work, you must put something there that
                  > > does work to be able to reproduce the problem.
                  >
                  > I understand the need for a crash-report to have the
                  > shortest possible reproducible example. I have tried, but
                  > have been unable to create a simple example.
                  >
                  > However, I can provide the original code and the steps to go
                  > through. When I go through those steps, gvim crashes.

                  This is too complicated to try out. I rather guess.

                  > First, here's a recap:
                  >
                  > Gvim is released 6.3, Big version with GUI, compiled
                  > Jun 7 2004 14:20:56. OS is Windows 98.
                  >
                  > After executing an embedded perl subroutine and returning
                  > SUCCESSFULLY from it, the gvim session crashes every once
                  > in about 3 times. The crash happens after the perl-code
                  > does its thing properly and returns control of gvim to the
                  > manual user.

                  Make sure you use the right DLL for Perl. That should be perl58.dll.
                  More precisely: ActivePerl 5.8.3.809.

                  > Crash happens even after doing the following in vimrc:
                  >
                  > let no_buffers_menu = 1
                  > let did_install_default_menus = 1
                  > let did_install_syntax_menu = 1
                  > set guioptions=a
                  >
                  > and unregistering gvim.

                  I don't see how registering/unregistering could be relevant.

                  > But crashes do not happen if, in the perl code, all the
                  > all the buffwipeout commands (:bw) are changed to
                  > bufunload (:bun).

                  This suggests it has something to do with pointers to a buffer becoming
                  invalid. Perhaps some of the Perl code remembers a pointer to a buffer,
                  which is accessed after it has been freed.

                  In the Perl interface code I can see the Buffers() function, which grabs
                  a list of pointers to buffers. This list will become invalid after a
                  ":bwipe".

                  Perhaps there are other parts in the Perl code where a buffer pointer is
                  used after the buffer was wiped out?

                  > A request: I looked at the description of your upcoming
                  > tutorial and noticed mention of using VIM for email. Please
                  > consider mentioning the tms.vim plugin to send, receive and
                  > organize email from within VIM!

                  I mention where to find scripts. I can't go through the list of
                  thousand scripts!

                  --
                  hundred-and-one symptoms of being an internet addict:
                  221. Your wife melts your keyboard in the oven.

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                  \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                • Suresh Govindachar
                  ... I have ActivePerl 5.8.0.804 -- a mismatch. [...] ... The crash happens after perl returns control to the manual user. This can be illustrated as follows:
                  Message 8 of 11 , Aug 30, 2004
                  • 0 Attachment
                    Bram Moolenaar Sent on 30 Aug 2004 10:47:50 +0200:

                    > Suresh Govindachar wrote:
                    >
                    >> Bram Moolenaar Sent: 29 Aug 2004 22:02:29 +0200:
                    >>
                    >> First, here's a recap:
                    >>
                    >> Gvim is released 6.3, Big version with GUI, compiled
                    >> Jun 7 2004 14:20:56. OS is Windows 98.
                    >>
                    >> After executing an embedded perl subroutine and
                    >> returning SUCCESSFULLY from it, the gvim session
                    >> crashes every once in about 3 times. The crash happens
                    >> after the perl-code does its thing properly and returns
                    >> control of gvim to the manual user.
                    >
                    > Make sure you use the right DLL for Perl. That should be
                    > perl58.dll. More precisely: ActivePerl 5.8.3.809.

                    I have ActivePerl 5.8.0.804 -- a mismatch.

                    [...]
                    >> But crashes do not happen if, in the perl code, all the
                    >> all the buffwipeout commands (:bw) are changed to
                    >> bufunload (:bun).
                    >
                    > This suggests it has something to do with pointers to a
                    > buffer becoming invalid. Perhaps some of the Perl code
                    > remembers a pointer to a buffer, which is accessed after
                    > it has been freed.
                    >
                    > In the Perl interface code I can see the Buffers()
                    > function, which grabs a list of pointers to buffers. This
                    > list will become invalid after a ":bwipe".
                    >
                    > Perhaps there are other parts in the Perl code where a
                    > buffer pointer is used after the buffer was wiped out?

                    The crash happens after perl returns control to the manual
                    user. This can be illustrated as follows:

                    nmap <buffer> <LocalLeader>d :perl VIM::Msg("Watch out for a VIM CRASH!:".tms_w_do_this('d').",");<CR>

                    The message that shows on issuing the above command (\d)
                    is: "Watch out for a VIM CRASH!:1," -- wherein the 1 is
                    the return value of the subroutine tms_w_do_this('d').
                    And the crash happens (on those occasions when it
                    happens) _after_ the message is displayed.

                    So perl has wiped out some buffers and returned; after
                    this, some non-user code is trying to access those
                    non-existent buffers.

                    Can a debug build of gvim capture this crash? More
                    generally, are there certain crashes of applications that
                    cannot be caught by a debug build of that application?

                    --Suresh
                  • Edward Peschko
                    hey all, A while ago, I heard talk about a debugger mode for vim, one where there was a split screen and you could use output from a gdb, dbg, or perl -d
                    Message 9 of 11 , Sep 8, 2004
                    • 0 Attachment
                      hey all,

                      A while ago, I heard talk about a debugger mode for vim, one where there
                      was a split screen and you could use output from a gdb, dbg, or perl -d session to
                      interact with files and do autmatic stepping through source code (and have
                      the code displayed in a split screen).

                      Did anything ever come out of this?

                      Ed
                    Your message has been successfully submitted and would be delivered to recipients shortly.