Alec Tica wrote:

>> First step is to try without Ruby. Most probably it is Ruby that
>> causes the problem.
>
> Yes, I also suspect ruby is the problem. If I'd be able to reproduce
> the bug using just ruby then I can report it directly to the ruby
> community. Is it something special in the way vim makes calls and
> inter-connects with the ruby interpreter? Using valgrind I get:
>
> ==8072== Invalid write of size 4
> ==8072==    at 0x823E333: ??? (in /usr/local/bin/vim)
> ==8072==    by 0x823E967: rb_thread_create (in /usr/local/bin/vim)
> ==8072==    by 0x733A668: pty_getpty (pty.c:442)
> ==8072==    by 0x822F884: ??? (in /usr/local/bin/vim)
> ==8072==    by 0x823794C: ??? (in /usr/local/bin/vim)
> ==8072==    by 0x8237AE8: ??? (in /usr/local/bin/vim)
> ==8072==    by 0x8241CF8: ??? (in /usr/local/bin/vim)
> ==8072==    by 0x82357B9: ??? (in /usr/local/bin/vim)
> ==8072==    by 0x82356D9: ??? (in /usr/local/bin/vim)
> ==8072==    by 0x8244DC9: ??? (in /usr/local/bin/vim)
> ==8072==    by 0x8245692: rb_eval_string (in /usr/local/bin/vim)
> ==8072==    by 0x82312E8: rb_protect (in /usr/local/bin/vim)
> ==8072==  Address 0xbe9f67b8 is just below the stack ptr.  To
> suppress, use: --workaround-gcc296-bugs=yes
> ==8072==
> Vim: Caught deadly signal VTALRM
> Vim: Finished.
> ==8072==
> ==8072== HEAP SUMMARY:
> ==8072==     in use at exit: 2,173,158 bytes in 30,633 blocks
> ==8072==   total heap usage: 166,041 allocs, 135,408 frees, 11,591,377
> bytes allocated
> ==8072==
> ==8072== LEAK SUMMARY:
> ==8072==    definitely lost: 10,510 bytes in 131 blocks
> ==8072==    indirectly lost: 15,195 bytes in 760 blocks
> ==8072==      possibly lost: 1,113,102 bytes in 14,355 blocks
> ==8072==    still reachable: 1,034,351 bytes in 15,387 blocks
> ==8072==         suppressed: 0 bytes in 0 blocks
> ==8072== Rerun with --leak-check=full to see details of leaked memory
> ==8072==
> ==8072== For counts of detected and suppressed errors, rerun with: -v
> ==8072== ERROR SUMMARY: 265 errors from 2 contexts (suppressed: 226 from 12)
>
> But, I have very little experience with valgrind, gdb and other such
> tools therefore I don't know if the above reveals anything useful.


For valgrind info to be useful, Vim should be built without
optimizations and with symbols (to avoid the ????? in the stack).

You can build Vim with symbols with minor changes to
vim/src/Makefile:

--- a/src/Makefile      Sat Jan 08 16:06:37 2011 +0100
+++ b/src/Makefile      Sun Jan 16 12:00:10 2011 +0100
@@ -554,7 +554,7 @@
 # Often used for GCC: mixed optimizing, lot of optimizing, debugging
 #CFLAGS = -g -O2 -fno-strength-reduce -Wall -Wshadow -Wmissing-prototypes
 #CFLAGS = -g -O2 -fno-strength-reduce -Wall -Wmissing-prototypes
-#CFLAGS = -g -Wall -Wmissing-prototypes
+CFLAGS = -g -O0 -Wall -Wmissing-prototypes
 #CFLAGS = -O6 -fno-strength-reduce -Wall -Wshadow -Wmissing-prototypes
 #CFLAGS = -g -DDEBUG -Wall -Wshadow -Wmissing-prototypes
 #CFLAGS = -g -O2 '-DSTARTUPTIME="vimstartup"' -fno-strength-reduce
-Wall -Wmissing-prototypes
@@ -1855,7 +1855,7 @@
          rm -f $(DEST_BIN)/$(VIMNAME).rm; \
        fi
        $(INSTALL_PROG) $(VIMTARGET) $(DEST_BIN)
-       $(STRIP) $(DEST_BIN)/$(VIMTARGET)
+       #$(STRIP) $(DEST_BIN)/$(VIMTARGET)
        chmod $(BINMOD) $(DEST_BIN)/$(VIMTARGET)
 # may create a link to the new executable from /usr/bin/vi
        -$(LINKIT)


I was able to reproduce the crash on Linux x86
with Vim-7.3.99 built with "libruby1.8.so" by running
a different script:

$ cat crash.vim
for i in range(1, 200)
  silent !ls -al
  ruby <<EOF
  require 'pty'
  $reader, $writer, $pid = PTY.spawn('ls -al')
EOF
endfor

$ vim -u NONE -c 'crash.vim'
...
Vim: Caught deadly signal VTALRM
Vim: Finished.
Virtual timer expired

Valgrind does not indicate any invalid memory access.
Vim just exits when receiving signal SIGVTALARM.

I'm not sure why Ruby uses SIGVTALARM but Vim
no longer exits with the attached patch.

Regards
-- Dominique

-- 
You received this message from the "vim_use" 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
diff -r 85c5a72551e2 src/os_unix.c
--- a/src/os_unix.c	Sat Jan 08 16:06:37 2011 +0100
+++ b/src/os_unix.c	Sun Jan 16 13:19:23 2011 +0100
@@ -283,7 +283,8 @@
 #ifdef SIGTERM
     {SIGTERM,	    "TERM",	TRUE},
 #endif
-#ifdef SIGVTALRM
+#if defined(SIGVTALRM) && !defined(FEAT_RUBY)
+    /* Ruby uses SIGVTALARM which makes Vim exit. */
     {SIGVTALRM,	    "VTALRM",	TRUE},
 #endif
 #if defined(SIGPROF) && !defined(FEAT_MZSCHEME) && !defined(WE_ARE_PROFILING)
@@ -1107,7 +1108,7 @@
  * On Linux, signal is not always handled immediately either.
  * See https://bugs.launchpad.net/bugs/291373
  *
- * volatile because it is used in in signal handler sigcont_handler().
+ * volatile because it is used in signal handler sigcont_handler().
  */
 static volatile int sigcont_received;
 static RETSIGTYPE sigcont_handler __ARGS(SIGPROTOARG);

Reply via email to