Dominique Pelle wrote: > afl-fuzz found a crash with vim-7.4.1273 (and older). > Vim-7.4.52 that comes with xubuntu-14.04 does not crash. > > I did a 'git bisect' to find when regression was introduced > and crash was introduced in this commit: > > === > $ git bisect bad > e0ad365498399c1bd34dd6361b3f7dc38e84e4ca is the first bad commit > commit e0ad365498399c1bd34dd6361b3f7dc38e84e4ca > Author: Bram Moolenaar <[email protected]> > Date: Tue Jan 27 12:59:55 2015 +0100 > > updated for version 7.4.593 > Problem: Crash when searching for "x\{0,90000}". (Dominique Pelle) > Solution: Bail out from the NFA engine when the max limit is much higher > than the min limit. > === > > Steps to reproduce the crash: > > $ vim -u NONE -N -S crash.vim > Vim: Caught deadly signal SEGV > > Press ENTER or type command to continueVim: Finished. > > Segmentation fault (core dumped) > > Where crash.vim is the attached file. > > Looking with gdb, vim crashes at ex_eval.c:1581 when > dereferencing current_exception which is NULL: > > Program received signal SIGSEGV, Segmentation fault. > ex_catch (eap=0x7fffffffc510) at ex_eval.c:1581 > > 1563│ save_cpo = p_cpo; > 1564│ p_cpo = (char_u *)""; > ! 1565│ regmatch.regprog = vim_regcomp(pat, RE_MAGIC > + RE_STRING); > 1566│ regmatch.rm_ic = FALSE; > 1567│ if (end != NULL) > 1568│ *end = save_char; > 1570│ if (regmatch.regprog == NULL) > 1571│ EMSG2(_(e_invarg2), pat); > 1572│ else > 1573│ { > 1574│ /* > 1575│ * Save the value of got_int and reset > it. We don't want > 1576│ * a previous interruption cancel > matching, only hitting > 1577│ * CTRL-C while matching should abort it. > 1578│ */ > 1579│ prev_got_int = got_int; > 1580│ got_int = FALSE; > !!1581├> caught = vim_regexec_nl(®match, > current_exception->value, > 1582│ (colnr_T)0); > 1583│ got_int |= prev_got_int; > 1584│ vim_regfree(regmatch.regprog); > 1585│ > > > (gdb) bt > #0 ex_catch (eap=0x7fffffffc510) at ex_eval.c:1581 [...] > > (gdb) p current_exception > $1 = (except_T *) 0x0 > (gdb) p did_throw > $2 = 0 > > I see that the block of code should not be entered if did_throw was 0 (see if > at ex_eval.c:1538). And in fact did_throw was 1 at line 1538, but it got > changed later to 0 when calling vim_regcomp(....) at line ex_eval.c:1565. > > Not sure how to fix this.
I can't reproduce it. Valgrind also doesn't report a problem. I also can't reproduce it with crash-catch.vim. The key appears to be that vim_regcomp() clears the exception that we are dealing with. How does that happen? We could either avoid that vim_regcomp() changes it, or get the exception before calling it. -- Microsoft says that MS-Windows is much better for you than Linux. That's like the Pope saying that catholicism is much better for you than protestantism. /// 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 /// -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
