2html.vim causes Vim to crash with a SIGSEGV?!

[Peter Odding]

Hi list,

Some days ago Ben Fritz CC'ed me from the "Generating html documentation
with hlink to jump easily" thread on vim_use [1] asking me to verify
that my publish plug-in [2] still works with 2html.vim after the recent
changes to 2html.vim.

So I tried it out and, while running the 2html script, Vim died with a
SIGSEGV signal. Since then I spent far too much time [3] learning how to
compile Vim with debugging symbols so that GDB would give me a useful
backtrace. I finally succeeded and got the attached backtrace `bt.txt'.
Because I don't have any experience in debugging Vim and/or using GDB
I'm now at a loss on how to continue debugging this issue. If there is
any more information I can extract from GDB or if there's something else
I can do to help others reproduce this issue please let me know.

Note that `PublishTest()' (referenced in `bt.txt') isn't defined in my
publish plug-in; it's defined in my ~/.vimrc and does basically the same
thing that the first Vim script snippet on [2] does. The main difference
is that it publishes 20 files instead of 4, except that those files
still aren't published because Vim keeps crashing :-). I don't think the
crash is related to which files are published...

- Peter Odding

[1]
http://groups.google.com/group/vim_use/browse_thread/thread/54c88aba79f8b42e/

[2] http://peterodding.com/code/vim/publish/

[3] I followed the instructions in :help debug.txt but didn't realize
that enabling "-g" doesn't disable "strip", which means Vim is first
compiled with debugging symbols but then the debugging symbols are
stripped before /usr/local/bin/vim is installed :-(. Maybe debug.txt
should be corrected as in the attached "debug-help-entry-fix.diff"?!

[Benjamin Fritz]

On Thu, Sep 2, 2010 at 8:49 AM, Peter Odding <pe...@peterodding.com> wrote:
>
> while running the 2html script, Vim died with a

> SIGSEGV signal. [Snip]

>
>
> Note that `PublishTest()' (referenced in `bt.txt') isn't defined in my
> publish plug-in; it's defined in my ~/.vimrc and does basically the same
> thing that the first Vim script snippet on [2] does. The main difference is
> that it publishes 20 files instead of 4, except that those files still
> aren't published because Vim keeps crashing :-). I don't think the crash is
> related to which files are published...
>

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?

[Peter Odding]

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...

[Dominique Pellé]

Peter Odding skribis:

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

[Peter Odding]

Hi Dominique,

> Which operating system and CPU are you using?

I'm running a 64 bit install of Ubuntu 9.10. The output of the command
`uname -a' is: Linux laptop 2.6.31-22-generic #61-Ubuntu SMP Wed Jul 28
02:02:56 UTC 2010 x86_64 GNU/Linux

> You can try to reproduce the bug with valgrind (if it's
> supported by your OS...).

Thanks for your suggestion. I just found out that the following line in
my ~/.vimrc is the apparent cause of the crash:

:set history=5000 viminfo='250,<0,r/tmp

Unfortunately the crash disappeared right around the time I realized
this, just before I received your message, which means I didn't get a
chance to run Vim under Valgrind. The crash hasn't reappeared since, so
I'm guessing the crash was related to the contents of my ~/.viminfo file
which has since been changed by Vim. Because I didn't realize ~/.viminfo
was involved until the crash disappeared I don't have a copy of the
faulty ~/.viminfo contents... :-(

I think the crash might be related to the highlighting of the last used
search pattern (from a previous Vim instance) because the backtrace I
posted earlier in this thread starts with regmatch(), regtry(),
vim_regexec_both(), etc. and the crash seemed to be related to the
contents of my ~/.viminfo file.

On the off chance that it's useful to some hardcore/psychic Vim hacker
I've attached my ~/.viminfo file to this message. I had to slightly
anonymize the file because of course it contains lots of info about my
private documents, I hope this doesn't make it useless; at least the
history of last used search patterns is intact, but don't ask me how
half those entries got there because I wouldn't know how to type those
non-ASCII characters anyway (I guess these entries are caused by Vim
plug-ins?!).

- Peter Odding

[Peter Odding]

Hi list,

After some more digging I isolated the cause of the crash and it has
nothing to do with 2html.vim: Vim crashes while evaluating a corrupt
regular expression generated by a bug in my publish.vim plug-in.

I initially suspected this problem but thought I'd excluded it when Vim
still crashed after I disabled the pattern's evaluation. I now think Vim
still crashed because the 'hlsearch' option caused Vim to evaluate the
last used search pattern stored in my ~/.viminfo file.

The regex is a 77 KB monstrosity that's supposed to match a predefined
set of strings in 2html.vim output and is complicated by the fact that
it also matches strings with embedded HTML tags. The regex is corrupt
because of a bug in my plug-in; I forgot to escape special characters
like [.

Even though the regex is corrupt (garbage in, garbage out) the crash
might still point towards a real bug, which is why I'm attaching a
script that demonstrates the crash. When I execute the script with the
following command I first get an E339 prompt and then Vim crashes with a
segmentation fault:

$ vim -u NONE --noplugin -NS crash.vim
Error detected while processing function <SNR>1_VimCrashOnRegexEval:
line 14:
E339: Pattern too long
Vim: Caught deadly signal SEGV
Vim: Finished.

I'm also attaching a backtrace from GDB and the output of Valgrind,
which tell me that Vim crashes because of a NULL pointer dereference at
regexp.c:4730 in the latest Vim 7.3 source. I've tried reasoning about
this but regmatch() is far too complex for my comprehension at the
moment :-)

- Peter Odding

[Carlo]

On Sep 5, 3:33 am, Peter Odding <pe...@peterodding.com> wrote:

> The regex is a 77 KB monstrosity that's supposed to match a predefined
> set of strings in 2html.vim output and is complicated by the fact that
> it also matches strings with embedded HTML tags. The regex is corrupt
> because of a bug in my plug-in; I forgot to escape special characters
> like [.

I can reproduce this crash with a much simpler, valid, regex:

$ vim -Ngfu NONE --noplugin -c "execute '/' . repeat('a\|', 9000) .
'a'"

Vim: Caught deadly signal SEGV

On my machine, it crashes with 9000 but not with 8000 repetitions.

> I'm also attaching a backtrace from GDB and the output of Valgrind,
> which tell me that Vim crashes because of a NULL pointer dereference at
> regexp.c:4730 in the latest Vim 7.3 source. I've tried reasoning about
> this but regmatch() is far too complex for my comprehension at the
> moment :-)

My backtrace is exactly the same:

(gdb) bt
#0 0x000000000055a545 in regmatch (scan=0x953cba "\003") at regexp.c:
4730
#1 0x0000000000557dd5 in regtry (prog=0x953ca0, col=0) at regexp.c:
3711
#2 0x0000000000557b9c in vim_regexec_both (line=0xabe7c0 "", col=0,
tm=0x0) at regexp.c:3600
#3 0x00000000005574c7 in vim_regexec (rmp=0x7fffffffdd00,
line=0xabe7c0 "", col=0) at regexp.c:3347
#4 0x00000000004b85cd in match_file_pat (pattern=0x0, prog=0x953ca0,
fname=0xabe7c0 "", sfname=0x0, tail=
0xabe7c0 "", allow_dirs=0) at fileio.c:10003
#5 0x00000000004b7bd2 in auto_next_pat (apc=0x7fffffffde50,
stop_at_last=0) at fileio.c:9525
#6 0x00000000004b77d8 in apply_autocmds_group (event=EVENT_VIMENTER,
fname=0xabe7c0 "", fname_io=0x0, force=0,
group=-3, buf=0x88c150, eap=0x0) at fileio.c:9358
#7 0x00000000004b7108 in apply_autocmds (event=EVENT_VIMENTER,
fname=0x0, fname_io=0x0, force=0, buf=0x88c150)
at fileio.c:8994
#8 0x00000000004d3973 in main (argc=6, argv=0x7fffffffe1e8) at main.c:
903

Carlo

(I attempted to post this message earlier but it somehow didn't make
it through)

>
>   - Peter Odding
>
> [crash.vim5K ]function! s:VimCrashOnRegexEval(tags)
>   let patterns = []
>   let short = s:IgnoreHTML('s') . s:IgnoreHTML(':')
>   let long = s:IgnoreHTML('&lt;') . s:IgnoreHTML('[Ss][Ii][Dd]') . s:IgnoreHTML('&gt;')
>   let prefix = '\%(' . short . '\|' . long . '\)'
>   for name in a:tags
>     let tokens = [prefix]
>     for token in split(name, '\W\@=\|\W\@<=')
>       " The bug in my original code was that I didn't escape special pattern characters in
>       " {token} before adding it to {tokens}, but that doesn't mean Vim should crash :-(
>       call add(tokens, s:IgnoreHTML(token))
>     endfor
>     call add(patterns, join(tokens, ''))
>   endfor
>   execute '/' . escape(join(patterns, '\|'), '~/')
> endfunction
>
> function! s:IgnoreHTML(s)
>   return printf('\%%(<[^/][^>]*>%s</[^>]\+>\|%s\)', a:s, a:s)
> endfunction
>
> call s:VimCrashOnRegexEval(['s:msg', 'g:loaded_publish', 'foreach_window', 's:ei_save',
>  \ 's:loaded_scripts', 'tex_fold_enabled', 'g:timer_verbosity', '<Tab>', 'reload_colors',
>  \ 'b:luainspect_syntax_error', 'g:easytags_resolve_links', 's:hif_save', 'unresolve_scriptname',
>  \ 'g:easytags_always_enabled', '<Home>', 'session#get_names', 's:directory', 'session#save_cmd',
>  \ 's:stal_save', 'session#auto_dirty_check', 'persist_special_windows', '<C-Down>',
>  \ 'b:luainspect_input', 'ignore_html', 's:ctags_filetypes', 'session#close_cmd', 's:object_methods',
>  \ 'xolox#timer#stop', 'easytags#highlight', 'g:session_autoload', 'g:publish_omit_dothtml',
>  \ 'save_plugin_window', 'netrw_hide', 'prep_cmdline', 's:cached_contents', 'g:lua_inspect_internal',
>  \ 'java_allow_cpp_keywords', 'open_at_cursor', 'luainspect#make_request', 'library_call',
>  \ 'xolox#debug', 'publish#run_rsync', 'easytags#get_tagsfile', 's:script', 'session#auto_load',
>  \ 'g:reload_on_write', 'easytags#read_tagsfile', 'publish#html_encode', '<Left>', 's:tagged_files',
>  \ 'easytags#update', 'xolox#path#absolute', 'easytags#map_filetypes', 'rename_variable',
>  \ 'publish#rsync_check', 'tex_flavor', '<Right>', 's:lock_files', 's:library_version', '<F11>',
>  \ 'g:html_ignore_folding', 's:has_reltime', 'g:html_number_lines', 'g:easytags_on_cursorhold',
>  \ 'save_qflist', 'g:easytags_autorecurse', 'find_tagged_files', 's:changed_path', 's:enoimpl',
>  \ 'escape_tags', 'g:loaded_session', 'xolox#timer#start', 'get_name', 'g:easytags_ignored_filetypes',
>  \ 'xolox#shell#open_cmd', 'xolox#quote_pattern', 'xolox#shell#execute', 'convert_value',
>  \ 'xolox#unique', 'session#path_to_name', '<Esc>[A', 'session#open_cmd', 'python_highlight_all',
>  \ '<A-Right>', 's:files_to_publish', 'define_default_styles', 's:supported_filetypes',
>  \ 'xolox#option#join', 's:loclist_to_window', 'session#delete_cmd', '<Esc>[23~', 'session#save_state',
>  \ '<Del>', 'vimsyn_noerror', 'publish#find_tags', 'reload_indent', 'xolox#shell#open_with',
>  \ 's:cached_filenames', 'xolox#reload#script', 'g:easytags_ctags_version', 'g:html_use_css',
>  \ 'clear_previous_matches', 'is_windows', 'session#save_colors', 'select_name',
>  \ 's:reload_script_active', 'session_is_locked', 'session#auto_unlock', 'set_tagged_files',
>  \ 'publish#create_subst_cmd', 'jump_to_window', 's:smd_save', 'g:xolox_message_buffer',
>  \ 'xolox#option#split_tags', 'g:easytags_cmd', 'xolox#path#equals', '<C-Up>', 'xolox#path#join',
>  \ 'xolox#warning', 's:hnl_save', 's:mls_save', 's:reloading_buffers', 's:aliases',
>  \ 'xolox#shell#fullscreen', 's:vim_filetypes', 'b:luainspect_warnings', 'cache_tagged_files',
>  \ 'easytags#autoload', 's:fullscreen_enabled', 'session#save_session', '<A-Left>', 'xolox#message',
>  \ 's:units', 'session#restart_cmd', 'g:timer_enabled', 's:contact', 'easytags#define_tagkind',
>  \ 'xolox#path#decode', '***', 'handle_error', 'reload_ftplugin', 'g:lua_inspect_warnings',
>  \ 's:session_is_dirty', 'xolox#shell#open_url', 'parse_scriptnames', 'session#save_features',
>  \ 'check_output', 'session#complete_names', '<C-S-PageUp>', 'xolox#path#relative', '<F3>',
>  \ 'b:easytags_last_highlighted', 'reload_message', 'update_warnings', 's:canonical_aliases',
>  \ 'reload_plugin', 's:go_toggled', 'publish#customize_html', 'g:shell_open_cmds', 'check_cfile',
>  \ 'run_ctags', '<C-S-PageDown>', 'g:loaded_luainspect', 'xolox#timer#format_timespan',
>  \ 'luainspect#highlight_cmd', 'xolox#reload#open_readonly', 'easytags#to_ctags_ft', 'pattern_to_lnum',
>  \ 'unlock_session', 'c_syntax_for_h', 'g:shell_fullscreen_items', 's:current_source_directory',
>  \ 'publish#create_dirs', 'reload_autoload', 'prepare_search_path', 's:viml_sl_prefix', 's:ruler_save',
>  \ 'is_bash', 'xolox#reload#windows', 'g:loaded_pyref', 's:cpo_save', 'has_dll', 'xolox#path#tempdir',
>  \ 'g:lua_inspect_events', 's:auto_reload_active', 'xolox#option#join_tags', 'highlight_variables',
>  \ 'xolox#escape#pattern', 'easytags#file_has_tags', 'check_filetype', 's:scripttypes',
>  \ 'script_sourced', 'b:luainspect_disabled', 'luainspect#auto_enable', '<c-]>', '<F5>',
>  \ 'session#view_cmd', 'xolox#path#commonprefix', 'g:easytags_include_members', 'g:session_autosave',
>  \ 'lock_session', 's:more_save', 's:huc_save', 'easytags#alias_filetypes', 'g:pyref_browser',
>  \ 'g:publish_viml_sl_hack', 's:tempdir_counter', 'easytags#supported_filetypes',
>  \ 'easytags#add_tagged_file', 'unescape_tags', 'filter_merge_tags', 'b:luainspect_output',
>  \ 'g:xolox_messages', 'xolox#shell#highlight_urls', 'session#auto_save', 'find_dll_version',
>  \ 's:window_to_info', 'b:easytags_nohl', 'easytags#write_tagsfile', 'g:loaded_easytags',
>  \ 'reload_buffers', '<F6>', 'reload_syntax', 'xolox#shell#is_fullscreen', 'publish#prep_env',
>  \ 's:groups', '<BS>', 'highlight_position', 's:tagkinds', 's:cached_layouts', 's:saved_qflist',
>  \ 'session#name_to_path', 'balloon_syntax', 'parse_text', 'xolox#path#merge', 'g:pyref_mapping',
>  \ 'publish#resolve_files', 'session#save_fullscreen', 'g:shell_mappings_enabled', 'xolox#path#encode',
>  \ 'reload_window', 'clear_message', 'xolox#escape#substitute', 'easytags#to_vim_ft',
>  \ 'xolox#option#split', 's:tags_to_publish', '...', 's:windows_compatible', 'g:publish_plaintext',
>  \ 'foreach_tabpage', 'xolox#shell#build_cmd', 'session#save_qflist', 'xolox#path#split'])
>
> [gdb.txt1K ]peter@laptop> gdb --args /usr/local/bin/gvim -fu NONE --noplugin -NS crash.vim
> GNU gdb (GDB) 7.0-ubuntu
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/local/bin/gvim...done.
> (gdb) r
> Starting program: /usr/local/bin/gvim -fu NONE --noplugin -NS crash.vim
> [Thread debugging using libthread_db enabled]
>
> (gvim:4029): GLib-WARNING **: g_set_prgname() called multiple times
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000564107 in regmatch (scan=0x97743a "\003") at regexp.c:4730
> 4730                    if (OP(next) != BRANCH) /* No choice. */
> (gdb) where
> #0  0x0000000000564107 in regmatch (scan=0x97743a "\003") at regexp.c:4730
> #1  0x0000000000561c50 in regtry (prog=0x977420, col=0) at regexp.c:3711
> #2  0x0000000000561a17 in vim_regexec_both (line=0xb93d50 "", col=0, tm=0x0) at regexp.c:3600
> #3  0x0000000000561342 in vim_regexec (rmp=0x7fffffffdf30, line=0xb93d50 "", col=0) at regexp.c:3347
> #4  0x00000000004c0d5d in match_file_pat (pattern=0x0, prog=0x977420, fname=0xb93d50 "", sfname=0x0, tail=0xb93d50 "", allow_dirs=0) at fileio.c:10003
> #5  0x00000000004c035e in auto_next_pat (apc=0x7fffffffe080, stop_at_last=0) at fileio.c:9525
> #6  0x00000000004bff4a in apply_autocmds_group (event=EVENT_VIMENTER, fname=0xb93d50 "", fname_io=0x0, force=0, group=-3, buf=0x8a1990, eap=0x0) at fileio.c:9358
> #7  0x00000000004bf860 in apply_autocmds (event=EVENT_VIMENTER, fname=0x0, fname_io=0x0, force=0, buf=0x8a1990) at fileio.c:8994
> #8  0x00000000004dc1dc in main (argc=6, argv=0x7fffffffe438) at main.c:903
>
>  valgrind.log
> 3KViewDownload

[ZyX]

Ответ на сообщение «Re: 2html.vim causes Vim to crash with a SIGSEGV?!»,
присланное в 20:09:39 11 сентября 2010, Суббота,
отправитель Carlo:

Confirmed, but before crashing it prints
Error detected while processing command line:
E339: Pattern too long
Command:
LANG=C vim -u NONE -c 'execute ''/''.repeat(''a\|'', 9000)'
(removed unneeded options). In the help file it is mentioned that
this error may occur only on systems with 16 bit ints:
This only happens on systems with 16 bit ints: The compiled regexp pattern is
longer than about 65000 characters. Try using a shorter pattern.
(message.txt, line 484)
And vim obviously should not crash.

Текст сообщения:

[Carlo]

I believe I've got a patch for this (see below).

First, if you look at the stacktrace in some detail in gdb, you'll see
that this error occurs while matching regexp ".*" against the current
filename ("" in this case) during autocmd execution. The crash occurs
because in line 4730, 'next' is null. In line 3888, 'next' is the
result of calling regnext(). regnext() returns NULL because global
variable reg_toolong is TRUE. But of course the pattern ".*" is not
too long - instead, this is left over from the evaluation of the
previous very long regexp ("a\|a\|a...").

This confusion occurs because regnext() is used both in compilation
and evaluation of regexes. Its behaviour of returning NULL if
reg_toolong is TRUE really only makes sense during compilation. The
easiest way to fix it is to just set reg_toolong to FALSE before
starting regexp evaluation, as in my patch. (It can only ever be set
to TRUE during the compilation phase.)

Carlo


diff --git a/src/regexp.c b/src/regexp.c
--- a/src/regexp.c
+++ b/src/regexp.c
@@ -3339,6 +3339,7 @@ vim_regexec(rmp, line, col)
reg_maxline = 0;
reg_line_lbr = FALSE;
reg_win = NULL;
+ reg_toolong = FALSE;
ireg_ic = rmp->rm_ic;
#ifdef FEAT_MBYTE
ireg_icombine = FALSE;
@@ -3363,6 +3364,7 @@ vim_regexec_nl(rmp, line, col)
reg_maxline = 0;
reg_line_lbr = TRUE;
reg_win = NULL;
+ reg_toolong = FALSE;
ireg_ic = rmp->rm_ic;
#ifdef FEAT_MBYTE
ireg_icombine = FALSE;
@@ -3399,6 +3401,7 @@ vim_regexec_multi(rmp, win, buf, lnum, c
reg_firstlnum = lnum;
reg_maxline = reg_buf->b_ml.ml_line_count - lnum;
reg_line_lbr = FALSE;
+ reg_toolong = FALSE;
ireg_ic = rmp->rmm_ic;
#ifdef FEAT_MBYTE
ireg_icombine = FALSE;

> ...
>
> read more »

[Peter Odding]

Hi Carlo,

I can confirm that the much simpler regex you posted also crashes Vim
(in the same way) and that your patch fixes the segmentation fault.
Thanks for taking the time to look into this and posting your patch!

Cheers,

- Peter Odding

[Carlo Teubner]

Peter Odding <peter <at> peterodding.com> writes:

>
> The regex is a 77 KB monstrosity that's supposed to match a predefined
> set of strings in 2html.vim output and is complicated by the fact that
> it also matches strings with embedded HTML tags. The regex is corrupt
> because of a bug in my plug-in; I forgot to escape special characters
> like [.

I can reproduce the same crash with a much simpler, valid, very long regex:
a\|a\|a\|...

$ vim -Ngfu NONE --noplugin -c "execute '/' . repeat('a\|', 9000) . 'a'"

Vim: Caught deadly signal SEGV

On my system, it crashes with 9000 repetitions but not 8000.

> I'm also attaching a backtrace from GDB and the output of Valgrind,
> which tell me that Vim crashes because of a NULL pointer dereference at
> regexp.c:4730 in the latest Vim 7.3 source. I've tried reasoning about
> this but regmatch() is far too complex for my comprehension at the
> moment

gdb shows the same backtrace as yours:

(gdb) bt
#0 0x000000000055a545 in regmatch (scan=0x953cba "\003") at regexp.c:4730
#1 0x0000000000557dd5 in regtry (prog=0x953ca0, col=0) at regexp.c:3711

#2 0x0000000000557b9c in vim_regexec_both (line=0xab3f30 "", col=0, tm=0x0) at
regexp.c:3600
#3 0x00000000005574c7 in vim_regexec (rmp=0x7fffffffdd00, line=0xab3f30 "",

col=0) at regexp.c:3347
#4 0x00000000004b85cd in match_file_pat (pattern=0x0, prog=0x953ca0,

fname=0xab3f30 "", sfname=0x0, tail=
0xab3f30 "", allow_dirs=0) at fileio.c:10003

#5 0x00000000004b7bd2 in auto_next_pat (apc=0x7fffffffde50, stop_at_last=0) at
fileio.c:9525
#6 0x00000000004b77d8 in apply_autocmds_group (event=EVENT_VIMENTER,

fname=0xab3f30 "", fname_io=0x0, force=0,

[Carlo]

On 11 Sep, 19:02, Carlo <carlo.teub...@gmail.com> wrote:
> I believe I've got a patch for this (see below).

Just changing the subject for visibility of my patch (same one
included again below). Apologies for the spam.

[Bram Moolenaar]

Carlo Teubner wrote:

> I believe I've got a patch for this (see below).
>
> First, if you look at the stacktrace in some detail in gdb, you'll see
> that this error occurs while matching regexp ".*" against the current
> filename ("" in this case) during autocmd execution. The crash occurs
> because in line 4730, 'next' is null. In line 3888, 'next' is the
> result of calling regnext(). regnext() returns NULL because global
> variable reg_toolong is TRUE. But of course the pattern ".*" is not
> too long - instead, this is left over from the evaluation of the
> previous very long regexp ("a\|a\|a...").
>
> This confusion occurs because regnext() is used both in compilation
> and evaluation of regexes. Its behaviour of returning NULL if
> reg_toolong is TRUE really only makes sense during compilation. The
> easiest way to fix it is to just set reg_toolong to FALSE before
> starting regexp evaluation, as in my patch. (It can only ever be set
> to TRUE during the compilation phase.)

Thank you very much for pinpointing the problem and making a patch.

I think it's a bit simpler to reset reg_toolong further down, then it's
needed only once.

--
hundred-and-one symptoms of being an internet addict:
124. You begin conversations with, "Who is your internet service provider?"

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///