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 -- [email protected] -- 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
