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

Re: Building on Windows 7 - Perl crashes

Expand Messages
  • Charles Cooper
    ... No idea about the crash, but here is some additional information: I have successfully built many vims through 7.3.618 on Windows 7 and have both python
    Message 1 of 12 , Aug 2 4:36 PM
    • 0 Attachment
      On Thursday, August 2, 2012 3:58:02 PM UTC-4, Bram Moolenaar wrote:
      > I have a new PC with Windows 7 that I want to use to build Vim for
      > distribution. It's a 64 bit system but I first want to build 32 bit
      > binaries.
      > I have installed MS C++ Express 2008, since the binaries from this
      > compiler run on most systems. Building the normal console and GUI
      > versions works fine.
      > Now building with all the interfaces. I installed:
      > Active State Perl 5.14 for x86
      > Python 2.7.3 (using Windows installer from python.org)
      > Python 3.2.3 (using Windows installer from python.org)
      > Ruby 1.9.2 (from www.garbagecollect.jp, see help file)
      > TCL 8.5.12 ActiveState Windows installer
      > XPM: get from the ftp site: ftp://ftp.vim.org/pub/vim/pcextra/xpm.zip
      > The Ruby install has 1.9.1 files even though I installed 1.9.2, very
      > I did some simple "hello world" tests and all appear to work, except
      > for Perl:
      > :perl VIM::Msg("Hello")
      > Vim crashes after printing "Hello".
      > Does anybody have an idea why the Perl 5.14 interface would load and do
      > something and then crash?

      No idea about the crash, but here is some additional information:
      I have successfully built many vims through 7.3.618 on Windows 7 and have both python 2.7.3 from python.org and self-built perls 5.14 and now 5.16. The same
      :perl VIM::Msg("Hello") has always worked without crashing. Compiled with MS C compiler from SDK 7.1. Same compiler used to builed the perls.

      --
      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
    • Bram Moolenaar
      ... So, it should work . I want to have a setup just like other users would have it, building Perl myself is not something I would tell everybody to do. It
      Message 2 of 12 , Aug 3 9:06 AM
      • 0 Attachment
        Charles Cooper wrote:

        > On Thursday, August 2, 2012 3:58:02 PM UTC-4, Bram Moolenaar wrote:
        > > I have a new PC with Windows 7 that I want to use to build Vim for
        > > distribution. It's a 64 bit system but I first want to build 32 bit
        > > binaries.
        > > I have installed MS C++ Express 2008, since the binaries from this
        > > compiler run on most systems. Building the normal console and GUI
        > > versions works fine.
        > > Now building with all the interfaces. I installed:
        > > Active State Perl 5.14 for x86
        > > Python 2.7.3 (using Windows installer from python.org)
        > > Python 3.2.3 (using Windows installer from python.org)
        > > Ruby 1.9.2 (from www.garbagecollect.jp, see help file)
        > > TCL 8.5.12 ActiveState Windows installer
        > > XPM: get from the ftp site: ftp://ftp.vim.org/pub/vim/pcextra/xpm.zip
        > > The Ruby install has 1.9.1 files even though I installed 1.9.2, very
        > > I did some simple "hello world" tests and all appear to work, except
        > > for Perl:
        > > :perl VIM::Msg("Hello")
        > > Vim crashes after printing "Hello".
        > > Does anybody have an idea why the Perl 5.14 interface would load and do
        > > something and then crash?
        >
        > No idea about the crash, but here is some additional information:
        > I have successfully built many vims through 7.3.618 on Windows 7 and
        > have both python 2.7.3 from python.org and self-built perls 5.14 and
        > now 5.16. The same
        > :perl VIM::Msg("Hello") has always worked without crashing. Compiled
        > with MS C compiler from SDK 7.1. Same compiler used to builed the
        > perls.

        So, "it should work". I want to have a setup just like other users
        would have it, building Perl myself is not something I would tell
        everybody to do.

        It might be something about how the .dll was build. Might even be a
        problem with using a 32 bit .dll on a 64 bit machine. What is the best
        way to find out where it crashes?

        --
        $ echo pizza > /dev/oven

        /// 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
      • Raymond Ko
        ... Salutations All, I m getting the same crash also using Microsoft Visual Studio 2010 Ultimate. The best way seems to let it crash, and after it failed the
        Message 3 of 12 , Aug 3 9:30 AM
        • 0 Attachment
          On Friday, August 3, 2012 12:06:39 PM UTC-4, Bram Moolenaar wrote:
          > Charles Cooper wrote:
          >
          >
          >
          > > On Thursday, August 2, 2012 3:58:02 PM UTC-4, Bram Moolenaar wrote:
          >
          > > > I have a new PC with Windows 7 that I want to use to build Vim for
          >
          > > > distribution. It's a 64 bit system but I first want to build 32 bit
          >
          > > > binaries.
          >
          > > > I have installed MS C++ Express 2008, since the binaries from this
          >
          > > > compiler run on most systems. Building the normal console and GUI
          >
          > > > versions works fine.
          >
          > > > Now building with all the interfaces. I installed:
          >
          > > > Active State Perl 5.14 for x86
          >
          > > > Python 2.7.3 (using Windows installer from python.org)
          >
          > > > Python 3.2.3 (using Windows installer from python.org)
          >
          > > > Ruby 1.9.2 (from www.garbagecollect.jp, see help file)
          >
          > > > TCL 8.5.12 ActiveState Windows installer
          >
          > > > XPM: get from the ftp site: ftp://ftp.vim.org/pub/vim/pcextra/xpm.zip
          >
          > > > The Ruby install has 1.9.1 files even though I installed 1.9.2, very
          >
          > > > I did some simple "hello world" tests and all appear to work, except
          >
          > > > for Perl:
          >
          > > > :perl VIM::Msg("Hello")
          >
          > > > Vim crashes after printing "Hello".
          >
          > > > Does anybody have an idea why the Perl 5.14 interface would load and do
          >
          > > > something and then crash?
          >
          > >
          >
          > > No idea about the crash, but here is some additional information:
          >
          > > I have successfully built many vims through 7.3.618 on Windows 7 and
          >
          > > have both python 2.7.3 from python.org and self-built perls 5.14 and
          >
          > > now 5.16. The same
          >
          > > :perl VIM::Msg("Hello") has always worked without crashing. Compiled
          >
          > > with MS C compiler from SDK 7.1. Same compiler used to builed the
          >
          > > perls.
          >
          >
          >
          > So, "it should work". I want to have a setup just like other users
          >
          > would have it, building Perl myself is not something I would tell
          >
          > everybody to do.
          >
          >
          >
          > It might be something about how the .dll was build. Might even be a
          >
          > problem with using a 32 bit .dll on a 64 bit machine. What is the best
          >
          > way to find out where it crashes?
          >
          >
          >
          > --
          >
          > $ echo pizza > /dev/oven
          >
          >
          >
          > /// 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 ///

          Salutations All,

          I'm getting the same crash also using Microsoft Visual Studio 2010 Ultimate.

          The best way seems to let it crash, and after it failed the "Checking for Possible Solutions" progress bar dialog, a "Debug" button should appear. This pops up the "Visual Studio Just-In-Time Debugger" and if you select "New Instance of Microsoft Visual Studio 20XX" it should fire up a new instance of VS in debug mode and you should see local variables and get a stack trace.

          Here is where it crashed for me:

          http://i.imgur.com/rkiaz.png

          Searching for the "length" variable, I do not see it initialized anywhere prior to use by SvPV(). Maybe this is triggering an out of bound read/write somewhere?

          --
          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
        • Bram Moolenaar
          ... The DLL distributed must have changed, but it was still called 191. Having a .h file in a directory with a version that differs from the distributed
          Message 4 of 12 , Aug 3 1:28 PM
          • 0 Attachment
            Ben Haskell wrote:

            > On Thu, 2 Aug 2012, Bram Moolenaar wrote:
            >
            > >
            > > I have a new PC with Windows 7 that I want to use to build Vim for
            > > distribution. [...]
            > >
            > > Now building with all the interfaces. I installed:
            > > [...]
            > > Ruby 1.9.2 (from www.garbagecollect.jp, see help file)
            > > Rename include dir from 1.9.1 to 1.9.2
            > > Remove check for _MSC_VER from config.h
            > > Copy bin/msvcrt-ruby191.dll to C:\Windows\msvcrt-ruby192.dll
            > > [...]
            > >
            > > The Ruby install has 1.9.1 files even though I installed 1.9.2, very
            > > confusing. I just renamed the files.
            >
            > Possibly important from a packaging perspective:
            >
            > You shouldn't have to rename the files. Ruby 1.9.2 and 1.9.3 are
            > "library compatible" with 1.9.1น. It seems like it'd be a PITA to have
            > to compile against a specific, non-standard version of Ruby.

            The DLL distributed must have changed, but it was still called 191.

            Having a .h file in a directory with a version that differs from the
            distributed version is not going to help anyone, just make things more
            complicated since there are two versions to specify. I'm trying not to
            call this a bug, but I would consider it.

            > The official (MRI) Ruby page points Windows users to:
            > http://rubyinstaller.org/
            >
            > However, it's compiled against MinGW. Is that one of the problems
            > (linking against different runtimes) the garbagecollect.jp version is
            > avoiding? The help (:help ruby) didn't seem particularly clear as to
            > why the weird version was required.

            I think it indeed matters what runtime it is compiled against. When
            building with MSVC I assume we do need the msvcrt version of the .dll.

            Anyway, it's just a hassle to do the renaming, it does appear to work.
            Unlike the Perl interface.

            --
            hundred-and-one symptoms of being an internet addict:
            205. You're constantly yelling at your spouse, family, roommate, whatever,
            for using the phone for stupid things...like talking.

            /// 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
          • Bram Moolenaar
            ... Thanks, that is very useful. ... length is set by the macro. Searching a bit suggested that PL_errgv might be NULL. And indeed, skipping the SvPV macro
            Message 5 of 12 , Aug 3 1:28 PM
            • 0 Attachment
              Raymond Ko wrote:

              > On Friday, August 3, 2012 12:06:39 PM UTC-4, Bram Moolenaar wrote:
              > > Charles Cooper wrote:
              > >
              > > > On Thursday, August 2, 2012 3:58:02 PM UTC-4, Bram Moolenaar wrote:
              > > > > I have a new PC with Windows 7 that I want to use to build Vim for
              > > > > distribution. It's a 64 bit system but I first want to build 32 bit
              > > > > binaries.
              > > > > I have installed MS C++ Express 2008, since the binaries from this
              > > > > compiler run on most systems. Building the normal console and GUI
              > > > > versions works fine.
              > > > > Now building with all the interfaces. I installed:
              > > > > Active State Perl 5.14 for x86
              > > > > Python 2.7.3 (using Windows installer from python.org)
              > > > > Python 3.2.3 (using Windows installer from python.org)
              > > > > Ruby 1.9.2 (from www.garbagecollect.jp, see help file)
              > > > > TCL 8.5.12 ActiveState Windows installer
              > > > > XPM: get from the ftp site: ftp://ftp.vim.org/pub/vim/pcextra/xpm.zip
              > > > > The Ruby install has 1.9.1 files even though I installed 1.9.2, very
              > > > > I did some simple "hello world" tests and all appear to work, except
              > > > > for Perl:
              > > > > :perl VIM::Msg("Hello")
              > > > > Vim crashes after printing "Hello".
              > > > > Does anybody have an idea why the Perl 5.14 interface would load and do
              > > > > something and then crash?
              > > >
              > > > No idea about the crash, but here is some additional information:
              > > > I have successfully built many vims through 7.3.618 on Windows 7 and
              > > > have both python 2.7.3 from python.org and self-built perls 5.14 and
              > > > now 5.16. The same
              > > > :perl VIM::Msg("Hello") has always worked without crashing. Compiled
              > > > with MS C compiler from SDK 7.1. Same compiler used to builed the
              > > > perls.
              > >
              > > So, "it should work". I want to have a setup just like other users
              > > would have it, building Perl myself is not something I would tell
              > > everybody to do.
              > >
              > > It might be something about how the .dll was build. Might even be a
              > > problem with using a 32 bit .dll on a 64 bit machine. What is the best
              > > way to find out where it crashes?
              >
              > Salutations All,
              >
              > I'm getting the same crash also using Microsoft Visual Studio 2010 Ultimate.
              >
              > The best way seems to let it crash, and after it failed the "Checking
              > for Possible Solutions" progress bar dialog, a "Debug" button should
              > appear. This pops up the "Visual Studio Just-In-Time Debugger" and if
              > you select "New Instance of Microsoft Visual Studio 20XX" it should
              > fire up a new instance of VS in debug mode and you should see local
              > variables and get a stack trace.
              >
              > Here is where it crashed for me:
              >
              > http://i.imgur.com/rkiaz.png

              Thanks, that is very useful.

              > Searching for the "length" variable, I do not see it initialized
              > anywhere prior to use by SvPV(). Maybe this is triggering an out of
              > bound read/write somewhere?

              "length" is set by the macro. Searching a bit suggested that PL_errgv
              might be NULL. And indeed, skipping the SvPV macro when PL_errgv is
              NULL solves the crash.

              However, it appears errors in perl_eval_sv() are now not reported, thus
              it's a workaround, not a solution.

              Perhaps there is a mismatch in the installed Perl version and the Vim
              compilation?

              --
              hundred-and-one symptoms of being an internet addict:
              206. You religiously respond immediately to e-mail, while ignoring
              your growing pile of snail mail.

              /// 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
            • James McCoy
              ... It should be. It s the same ABI. ... Ruby s distribution version and its ABI version are two separate things. Ruby based the ABI on the full version of
              Message 6 of 12 , Aug 3 3:44 PM
              • 0 Attachment
                On Fri, Aug 03, 2012 at 10:28:48PM +0200, Bram Moolenaar wrote:
                >
                > Ben Haskell wrote:
                >
                > > On Thu, 2 Aug 2012, Bram Moolenaar wrote:
                > >
                > > >
                > > > I have a new PC with Windows 7 that I want to use to build Vim for
                > > > distribution. [...]
                > > >
                > > > Now building with all the interfaces. I installed:
                > > > [...]
                > > > Ruby 1.9.2 (from www.garbagecollect.jp, see help file)
                > > > Rename include dir from 1.9.1 to 1.9.2
                > > > Remove check for _MSC_VER from config.h
                > > > Copy bin/msvcrt-ruby191.dll to C:\Windows\msvcrt-ruby192.dll
                > > > [...]
                > > >
                > > > The Ruby install has 1.9.1 files even though I installed 1.9.2, very
                > > > confusing. I just renamed the files.
                > >
                > > Possibly important from a packaging perspective:
                > >
                > > You shouldn't have to rename the files. Ruby 1.9.2 and 1.9.3 are
                > > "library compatible" with 1.9.1น. It seems like it'd be a PITA to have
                > > to compile against a specific, non-standard version of Ruby.
                >
                > The DLL distributed must have changed, but it was still called 191.

                It should be. It's the same ABI.

                > Having a .h file in a directory with a version that differs from the
                > distributed version is not going to help anyone, just make things more
                > complicated since there are two versions to specify. I'm trying not to
                > call this a bug, but I would consider it.

                Ruby's distribution version and its ABI version are two separate things.
                Ruby based the ABI on the full version of the last ABI break (1.9.1).

                This is similar to what happens with Perl, Python, Lua, and many other
                projects except they tend to base the ABI version on major.minor.

                --
                James
                GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@...>
              • Raymond Ko
                ... Although I am not an expert at Perl bindings by any means, I just noticed this interesting fact: Compiling with the latest MinGW from
                Message 7 of 12 , Aug 6 7:46 AM
                • 0 Attachment
                  On Friday, August 3, 2012 4:28:49 PM UTC-4, Bram Moolenaar wrote:
                  > Raymond Ko wrote:
                  >
                  >
                  >
                  > > On Friday, August 3, 2012 12:06:39 PM UTC-4, Bram Moolenaar wrote:
                  >
                  > > > Charles Cooper wrote:
                  >
                  > > >
                  >
                  > > > > On Thursday, August 2, 2012 3:58:02 PM UTC-4, Bram Moolenaar wrote:
                  >
                  > > > > > I have a new PC with Windows 7 that I want to use to build Vim for
                  >
                  > > > > > distribution. It's a 64 bit system but I first want to build 32 bit
                  >
                  > > > > > binaries.
                  >
                  > > > > > I have installed MS C++ Express 2008, since the binaries from this
                  >
                  > > > > > compiler run on most systems. Building the normal console and GUI
                  >
                  > > > > > versions works fine.
                  >
                  > > > > > Now building with all the interfaces. I installed:
                  >
                  > > > > > Active State Perl 5.14 for x86
                  >
                  > > > > > Python 2.7.3 (using Windows installer from python.org)
                  >
                  > > > > > Python 3.2.3 (using Windows installer from python.org)
                  >
                  > > > > > Ruby 1.9.2 (from www.garbagecollect.jp, see help file)
                  >
                  > > > > > TCL 8.5.12 ActiveState Windows installer
                  >
                  > > > > > XPM: get from the ftp site: ftp://ftp.vim.org/pub/vim/pcextra/xpm.zip
                  >
                  > > > > > The Ruby install has 1.9.1 files even though I installed 1.9.2, very
                  >
                  > > > > > I did some simple "hello world" tests and all appear to work, except
                  >
                  > > > > > for Perl:
                  >
                  > > > > > :perl VIM::Msg("Hello")
                  >
                  > > > > > Vim crashes after printing "Hello".
                  >
                  > > > > > Does anybody have an idea why the Perl 5.14 interface would load and do
                  >
                  > > > > > something and then crash?
                  >
                  > > > >
                  >
                  > > > > No idea about the crash, but here is some additional information:
                  >
                  > > > > I have successfully built many vims through 7.3.618 on Windows 7 and
                  >
                  > > > > have both python 2.7.3 from python.org and self-built perls 5.14 and
                  >
                  > > > > now 5.16. The same
                  >
                  > > > > :perl VIM::Msg("Hello") has always worked without crashing. Compiled
                  >
                  > > > > with MS C compiler from SDK 7.1. Same compiler used to builed the
                  >
                  > > > > perls.
                  >
                  > > >
                  >
                  > > > So, "it should work". I want to have a setup just like other users
                  >
                  > > > would have it, building Perl myself is not something I would tell
                  >
                  > > > everybody to do.
                  >
                  > > >
                  >
                  > > > It might be something about how the .dll was build. Might even be a
                  >
                  > > > problem with using a 32 bit .dll on a 64 bit machine. What is the best
                  >
                  > > > way to find out where it crashes?
                  >
                  > >
                  >
                  > > Salutations All,
                  >
                  > >
                  >
                  > > I'm getting the same crash also using Microsoft Visual Studio 2010 Ultimate.
                  >
                  > >
                  >
                  > > The best way seems to let it crash, and after it failed the "Checking
                  >
                  > > for Possible Solutions" progress bar dialog, a "Debug" button should
                  >
                  > > appear. This pops up the "Visual Studio Just-In-Time Debugger" and if
                  >
                  > > you select "New Instance of Microsoft Visual Studio 20XX" it should
                  >
                  > > fire up a new instance of VS in debug mode and you should see local
                  >
                  > > variables and get a stack trace.
                  >
                  > >
                  >
                  > > Here is where it crashed for me:
                  >
                  > >
                  >
                  > > http://i.imgur.com/rkiaz.png
                  >
                  >
                  >
                  > Thanks, that is very useful.
                  >
                  >
                  >
                  > > Searching for the "length" variable, I do not see it initialized
                  >
                  > > anywhere prior to use by SvPV(). Maybe this is triggering an out of
                  >
                  > > bound read/write somewhere?
                  >
                  >
                  >
                  > "length" is set by the macro. Searching a bit suggested that PL_errgv
                  >
                  > might be NULL. And indeed, skipping the SvPV macro when PL_errgv is
                  >
                  > NULL solves the crash.
                  >
                  >
                  >
                  > However, it appears errors in perl_eval_sv() are now not reported, thus
                  >
                  > it's a workaround, not a solution.
                  >
                  >
                  >
                  > Perhaps there is a mismatch in the installed Perl version and the Vim
                  >
                  > compilation?
                  >
                  >
                  >
                  > --
                  >
                  > hundred-and-one symptoms of being an internet addict:
                  >
                  > 206. You religiously respond immediately to e-mail, while ignoring
                  >
                  > your growing pile of snail mail.
                  >
                  >
                  >
                  > /// 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 ///

                  Although I am not an expert at Perl bindings by any means, I just noticed this interesting fact: Compiling with the latest MinGW from http://sourceforge.net/projects/mingwbuilds/files/windows-host/ (i686-mingw-w64-gcc-4.7.1-release-c,c++,fortran-sjlj-rev2.7z) does not make Perl bindings crash (tested with :perl VIM::Msg("hello")).

                  If the dependencies of executables produced by MinGW is similar to MSVC 2008 Express, then it might be a possible option to produce official Windows binaries with MinGW instead. The Make_ming.mak file should be tweaked to use "-O2 -flto -fwhole-program" as optimization flags (-O3 produced a miscompiled VIM binary that crashes).

                  The only tradeoff of using MinGW, at least in my experience, is that you can't use the JIT Debugging as mentioned in my previous post, making post-mortem debugging and stacktraces impossible, and that there is no profiling tools available for MinGW like in MSVC. This shouldn't really affect end users though. In fact, if you want to use the Command-T plugin for VIM on Windows, you have to use MinGW as it has a C extension for the Ruby bindings. My guess is that Ruby C bindings are in C99, which MSVC does not support, and as a result it does not compile. Of course this assumes you are using Ruby from http://rubyinstaller.org/ which includes a DevKit to allow you compile C extensions.

                  Based on some random googling, the whole issue seems to be related to this bug, which is supposedly fixed?:
                  https://rt.perl.org/rt3/Public/Bug/Display.html?id=20772

                  --
                  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
                • Bram Moolenaar
                  Raymond Ko wrote: [...] ... I have had problems with MingW in the past. I prefer to build with MSVC. Sticking with one compiler usually works best, other
                  Message 8 of 12 , Aug 6 11:29 AM
                  • 0 Attachment
                    Raymond Ko wrote:

                    [...]

                    > > > Here is where it crashed for me:
                    > > > http://i.imgur.com/rkiaz.png
                    > >
                    > > Thanks, that is very useful.
                    > >
                    > > > Searching for the "length" variable, I do not see it initialized
                    > > > anywhere prior to use by SvPV(). Maybe this is triggering an out of
                    > > > bound read/write somewhere?
                    > >
                    > > "length" is set by the macro. Searching a bit suggested that PL_errgv
                    > > might be NULL. And indeed, skipping the SvPV macro when PL_errgv is
                    > > NULL solves the crash.
                    > >
                    > > However, it appears errors in perl_eval_sv() are now not reported, thus
                    > > it's a workaround, not a solution.
                    > >
                    > > Perhaps there is a mismatch in the installed Perl version and the Vim
                    > > compilation?
                    >
                    > Although I am not an expert at Perl bindings by any means, I just
                    > noticed this interesting fact: Compiling with the latest MinGW from
                    > http://sourceforge.net/projects/mingwbuilds/files/windows-host/
                    > (i686-mingw-w64-gcc-4.7.1-release-c,c++,fortran-sjlj-rev2.7z) does not
                    > make Perl bindings crash (tested with :perl VIM::Msg("hello")).
                    >
                    > If the dependencies of executables produced by MinGW is similar to
                    > MSVC 2008 Express, then it might be a possible option to produce
                    > official Windows binaries with MinGW instead. The Make_ming.mak file
                    > should be tweaked to use "-O2 -flto -fwhole-program" as optimization
                    > flags (-O3 produced a miscompiled VIM binary that crashes).

                    I have had problems with MingW in the past. I prefer to build with
                    MSVC. Sticking with one compiler usually works best, other compilers
                    have other problems...

                    > The only tradeoff of using MinGW, at least in my experience, is that
                    > you can't use the JIT Debugging as mentioned in my previous post,
                    > making post-mortem debugging and stacktraces impossible, and that
                    > there is no profiling tools available for MinGW like in MSVC. This
                    > shouldn't really affect end users though. In fact, if you want to use
                    > the Command-T plugin for VIM on Windows, you have to use MinGW as it
                    > has a C extension for the Ruby bindings. My guess is that Ruby C
                    > bindings are in C99, which MSVC does not support, and as a result it
                    > does not compile. Of course this assumes you are using Ruby from
                    > http://rubyinstaller.org/ which includes a DevKit to allow you compile
                    > C extensions.
                    >
                    > Based on some random googling, the whole issue seems to be related to
                    > this bug, which is supposedly fixed?:
                    > https://rt.perl.org/rt3/Public/Bug/Display.html?id=20772

                    If it is already fixed, then in what version? And where is it broken?
                    I did install the latest version of Perl. I prefer the Vim code to work
                    with most Perl versions anyway.

                    --
                    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/ \\\
                    \\\ 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
                  • Raymond Ko
                    ... After some careful re-reading, I might have been too hasty in posting that link. It was for Perl 5.6 and Linux. Just thought it might be relevant since it
                    Message 9 of 12 , Aug 6 6:55 PM
                    • 0 Attachment
                      On Monday, August 6, 2012 2:29:41 PM UTC-4, Bram Moolenaar wrote:
                      > Raymond Ko wrote:
                      >
                      >
                      >
                      > [...]
                      >
                      >
                      >
                      > > > > Here is where it crashed for me:
                      >
                      > > > > http://i.imgur.com/rkiaz.png
                      >
                      > > >
                      >
                      > > > Thanks, that is very useful.
                      >
                      > > >
                      >
                      > > > > Searching for the "length" variable, I do not see it initialized
                      >
                      > > > > anywhere prior to use by SvPV(). Maybe this is triggering an out of
                      >
                      > > > > bound read/write somewhere?
                      >
                      > > >
                      >
                      > > > "length" is set by the macro. Searching a bit suggested that PL_errgv
                      >
                      > > > might be NULL. And indeed, skipping the SvPV macro when PL_errgv is
                      >
                      > > > NULL solves the crash.
                      >
                      > > >
                      >
                      > > > However, it appears errors in perl_eval_sv() are now not reported, thus
                      >
                      > > > it's a workaround, not a solution.
                      >
                      > > >
                      >
                      > > > Perhaps there is a mismatch in the installed Perl version and the Vim
                      >
                      > > > compilation?
                      >
                      > >
                      >
                      > > Although I am not an expert at Perl bindings by any means, I just
                      >
                      > > noticed this interesting fact: Compiling with the latest MinGW from
                      >
                      > > http://sourceforge.net/projects/mingwbuilds/files/windows-host/
                      >
                      > > (i686-mingw-w64-gcc-4.7.1-release-c,c++,fortran-sjlj-rev2.7z) does not
                      >
                      > > make Perl bindings crash (tested with :perl VIM::Msg("hello")).
                      >
                      > >
                      >
                      > > If the dependencies of executables produced by MinGW is similar to
                      >
                      > > MSVC 2008 Express, then it might be a possible option to produce
                      >
                      > > official Windows binaries with MinGW instead. The Make_ming.mak file
                      >
                      > > should be tweaked to use "-O2 -flto -fwhole-program" as optimization
                      >
                      > > flags (-O3 produced a miscompiled VIM binary that crashes).
                      >
                      >
                      >
                      > I have had problems with MingW in the past. I prefer to build with
                      >
                      > MSVC. Sticking with one compiler usually works best, other compilers
                      >
                      > have other problems...
                      >
                      >
                      >
                      > > The only tradeoff of using MinGW, at least in my experience, is that
                      >
                      > > you can't use the JIT Debugging as mentioned in my previous post,
                      >
                      > > making post-mortem debugging and stacktraces impossible, and that
                      >
                      > > there is no profiling tools available for MinGW like in MSVC. This
                      >
                      > > shouldn't really affect end users though. In fact, if you want to use
                      >
                      > > the Command-T plugin for VIM on Windows, you have to use MinGW as it
                      >
                      > > has a C extension for the Ruby bindings. My guess is that Ruby C
                      >
                      > > bindings are in C99, which MSVC does not support, and as a result it
                      >
                      > > does not compile. Of course this assumes you are using Ruby from
                      >
                      > > http://rubyinstaller.org/ which includes a DevKit to allow you compile
                      >
                      > > C extensions.
                      >
                      > >
                      >
                      > > Based on some random googling, the whole issue seems to be related to
                      >
                      > > this bug, which is supposedly fixed?:
                      >
                      > > https://rt.perl.org/rt3/Public/Bug/Display.html?id=20772
                      >
                      >
                      >
                      > If it is already fixed, then in what version? And where is it broken?
                      >
                      > I did install the latest version of Perl. I prefer the Vim code to work
                      >
                      > with most Perl versions anyway.
                      >
                      >
                      >
                      > --
                      >
                      > 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/ \\\
                      >
                      > \\\ an exciting new programming language -- http://www.Zimbu.org ///
                      >
                      > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                      After some careful re-reading, I might have been too hasty in posting that link. It was for Perl 5.6 and Linux. Just thought it might be relevant since it seems to use the same way to retrieve errors.

                      A more relevant post I found is this:
                      http://sourceforge.net/mailarchive/forum.php?thread_name=20111121203748.GA2514%40whitehatsec.com&forum_name=swig-devel
                      , which seems to exactly describe this problem. And indeed, using ActiveState Perl 5.12 works for print "hello" without crashing and can report errors. From the comments in the post, they offer a workaround, which I have based the following patch on. It is somewhat ugly as I had to use the preprocessor to check for MS VC is being used (since MinGW doesn't need fixing). I am not sure if the error messages obtained differ from PL_errgv method, although through my one test, they appear to be the same.

                      IMO, I think this stems from ActiveState's choice to use the woefully outdated VC6 to compile Perl to ensure maximum compatibility on all Windows systems. Using VC6 links to the VC6 runtime (msvcrt.dll). Since we are using newer versions of MSVC, it is using different version of the C++ Runtime Library, which might be causing conflicts. It is that or some other ABI incompatibility I think.

                      I also tried using Strawberry Perl, although that wouldn't compile.

                      Based of all this I think the following options are:
                      1. Use ActiveState Perl 5.12 and say that is the official version of Windows binaries.
                      2. Use the patch and just fix it for MS VC and Perl >= 5.14
                      3. Use a variant of the patch and always use perl_get_sv(). I don't know if this is available or equivalent in older versions, or what the ramifications are.
                      4. Find a Windows Perl maintainer to investigate the root cause and recommended fix, as none of this stuff is my forte.

                      --
                      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
                    • Bram Moolenaar
                      ... Thanks! I ll try it out tomorrow. -- From the classified section of a city newspaper: Dog for sale: eats anything and is fond of children. /// Bram
                      Message 10 of 12 , Aug 7 12:45 PM
                      • 0 Attachment
                        Raymond Ko wrote:

                        > After some careful re-reading, I might have been too hasty in posting
                        > that link. It was for Perl 5.6 and Linux. Just thought it might be
                        > relevant since it seems to use the same way to retrieve errors.
                        >
                        > A more relevant post I found is this:
                        > http://sourceforge.net/mailarchive/forum.php?thread_name=20111121203748.GA2514%40whitehatsec.com&forum_name=swig-devel
                        > , which seems to exactly describe this problem. And indeed, using
                        > ActiveState Perl 5.12 works for print "hello" without crashing and can
                        > report errors. From the comments in the post, they offer a workaround,
                        > which I have based the following patch on. It is somewhat ugly as I
                        > had to use the preprocessor to check for MS VC is being used (since
                        > MinGW doesn't need fixing). I am not sure if the error messages
                        > obtained differ from PL_errgv method, although through my one test,
                        > they appear to be the same.
                        >
                        > IMO, I think this stems from ActiveState's choice to use the woefully
                        > outdated VC6 to compile Perl to ensure maximum compatibility on all
                        > Windows systems. Using VC6 links to the VC6 runtime (msvcrt.dll).
                        > Since we are using newer versions of MSVC, it is using different
                        > version of the C++ Runtime Library, which might be causing conflicts.
                        > It is that or some other ABI incompatibility I think.
                        >
                        > I also tried using Strawberry Perl, although that wouldn't compile.
                        >
                        > Based of all this I think the following options are:
                        > 1. Use ActiveState Perl 5.12 and say that is the official version of
                        > Windows binaries.
                        > 2. Use the patch and just fix it for MS VC and Perl >= 5.14
                        > 3. Use a variant of the patch and always use perl_get_sv(). I don't
                        > know if this is available or equivalent in older versions, or what the
                        > ramifications are.
                        > 4. Find a Windows Perl maintainer to investigate the root cause and
                        > recommended fix, as none of this stuff is my forte.

                        Thanks! I'll try it out tomorrow.


                        --
                        From the classified section of a city newspaper:
                        Dog for sale: eats anything and is fond of children.

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