I found a cause of crash. This is happend on windows only. Distribution of ruby-win32 include a header file 'ruby/win32.h' that has some defines of types(ex: off_t). And my distribution's one is: #define off_t __int64 (8byte). But MSVC's one is 'typedef long off_t;' (4byte) . Thus, it make problem that offsetof(buf_T,b_ruby_ref) in 'if_ruby.c' is different from other's offsetof(buf_T,if_ruby_ref) .
I wrote a patch for this problem. Please check and include. It works fine for me. :) Everyone: please check this in other OS. Thanks. - Yasuhiro Matsumoto diff -r fae782ef63dd src/if_ruby.c --- a/src/if_ruby.c Thu Sep 30 21:47:56 2010 +0200 +++ b/src/if_ruby.c Fri Oct 08 14:23:21 2010 +0900 @@ -79,6 +79,8 @@ # define rb_int2big rb_int2big_stub #endif +#include <sys/types.h> + #include <ruby.h> #ifdef RUBY19_OR_LATER # include <ruby/encoding.h> On Oct 6, 6:58 pm, mattn <[email protected]> wrote: > So I sent following e-mail to google group, Sorry about duplicate > post. > ------------- > Hi all. > > It seems that breaks in if_ruby(or buffer.c ?) > > # vim > :help > :ruby p VIM::Buffer[1] <= crash > > I found weird behavior in buffer.c > > when type :help, it goes under the code in buffer.c 1696: > > #ifdef FEAT_SYN_HL > hash_init(&(buf->b_s.b_keywtab)); // A > hash_init(&(buf->b_s.b_keywtab_ic)); // B > #endif > > When pass to A, buf->b_python_ref become 0x0f from 0x00. > I don't use python in this case. Maybe something is the matter with > allocate/copying memory... > > Thanks. -- 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
