Peter Odding skribis: > Hi Benjamin, > >> It might actually be related. If 2html is doing something wrong, it >> must only be on certain inputs, because I have a test suite I run it >> through that uses an exhaustive set of all the options (except for >> font, encoding, and no_progressbar), and have never seen a crash: >> >> http://code.google.com/p/vim-2html-test >> >> Maybe you could give a sample of the input that crashes Vim? > > You're right in that it doesn't unconditionally crash, sorry for my alarming > initial message. Unfortunately the cause appears to be an interaction > between the updated 2html.vim script and my Vim profile (probably an > automatic command). This means I get to go through the whole <manual binary > search by disabling blocks of code and checking whether it still crashes> > ritual. I'll get back to you in a few days once I've checked every > permutation of interacting code in my Vim profile :-( > > - Peter Odding > > PS. I've already tried :set vbs=15 and :redir > ~/crash.log but the log file > gets cut of somewhere mid sentence without an obvious cause for the crash in > the preceding lines...
Hi Peter Which operating system and CPU are you using? You can try to reproduce the bug with valgrind (if it's supported by your OS...). It's easy: 1) install valgrind On ubuntu, you can install it with: $ sudo apt-get install valgrind 2) run Vim with valgrind. You only need to prefix your command line with something like "valgrind --log-file=vg.log". Example: $ valgrind --log-file=valgrind.log vim You then do the same thing as you would normally do in Vim. Vim will be much slower with Valgrind but bugs which access illegal memory (free block or uninitialized memory for example) will be detected and logged with a stack trace in log file valgrind.log. -- Dominique -- 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
