Re: Vim crash with large xpm
I just tried the file. Opening Vim took about a minute with Vim
running at 100% CPU after which Vim became responsive. I then scrolled
down by repeating 99 and just before I reached the bitmap
part of the XPM file Vim crashed. I've tried a few times and it
crashes every time, but only after reaching the bitmap part.
There are way too many syntax groups, and they overflow into syntax
clusters, because clusters are stored in a high part of the syntax group
id number-space, and Vim doesn't check it.
The attached preliminary patch puts in a check for this and a couple of
other possible syntax overflow conditions, so we should get errors, not
crashes.
It fixes this particular problem for me. An error occurs when the file
is loaded, and scrolling is slow, but doesn't crash, and can be
interrupted with control-C.
Can others test this and confirm?
Bram, if you're happy with this approach, I can tidy up the patch a bit,
i.e. put in error message numbers, including in the documentation, if
that's helpful.
Ben.
--
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
# HG changeset patch
# Parent c9bc095adaae71c79d2382c27601390ae2008201
diff --git a/src/syntax.c b/src/syntax.c
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -229,6 +229,7 @@
#define SYNID_TOP 15000 /* syntax group ID for contains=TOP */
#define SYNID_CONTAINED 2 /* syntax group ID for contains=CONTAINED */
#define SYNID_CLUSTER 25000 /* first syntax group ID for clusters */
+#define MAX_SYN_INC_TAG 4999 /* maximum before the above overflow */
/*
* Annoying Hack(TM): ":syn include" needs this pointer to pass to
@@ -4661,6 +4662,11 @@
return;
}
sgl_id = syn_check_cluster(arg, (int)(group_name_end - arg));
+ if (sgl_id == 0)
+ {
+ EMSG((char_u *)_("Exxx: Too many syntax clusters"));
+ return;
+ }
/* separate_nextcmd() and expand_filename() depend on this */
eap->arg = rest;
}
@@ -4689,6 +4695,11 @@
* Save and restore the existing top-level grouplist id and ":syn
* include" tag around the actual inclusion.
*/
+if (running_syn_inc_tag >= MAX_SYN_INC_TAG)
+{
+ EMSG((char_u *)_("Exxx: Too many syntax includes"));
+ return;
+}
prev_syn_inc_tag = current_syn_inc_tag;
current_syn_inc_tag = ++running_syn_inc_tag;
prev_toplvl_grp = curwin->w_s->b_syn_topgrp;
@@ -4725,8 +4736,18 @@
{
syn_id = syn_check_group(arg, (int)(group_name_end - arg));
- /* allocate a buffer, for removing the backslashes in the keyword */
- keyword_copy = alloc((unsigned)STRLEN(rest) + 1);
+ if (syn_id == 0)
+ {
+ /* if we can't create the syntax group, don't allocate a buffer so
+ * that we fail */
+ keyword_copy = NULL;
+ }
+ else
+ {
+ /* allocate a buffer, for removing the backslashes in the keyword */
+ keyword_copy = alloc((unsigned)STRLEN(rest) + 1);
+ }
+
if (keyword_copy != NULL)
{
syn_opt_arg.flags = 0;
@@ -5426,6 +5447,14 @@
curwin->w_s->b_syn_clusters.ga_growsize = 10;
}
+/* Fail if syntax group IDs overflow */
+len = curwin->w_s->b_syn_clusters.ga_len;
+if (len + SYNID_CLUSTER < SYNID_CLUSTER)
+{
+ vim_free(name);
+ return 0;
+}
+
/*
* Make room for at least one other cluster entry.
*/
@@ -5476,41 +5505,48 @@
if (rest != NULL)
{
- scl_id = syn_check_cluster(arg, (int)(group_name_end - arg))
- - SYNID_CLUSTER;
-
- for (;;)
- {
- if (STRNICMP(rest, "add", 3) == 0
- && (vim_iswhite(rest[3]) || rest[3] == '='))
- {
- opt_len = 3;
- list_op = CLUSTER_ADD;
- }
- else if (STRNICMP(rest, "remove", 6) == 0
- && (vim_iswhite(rest[6]) || rest[6] == '='))
- {
- opt_len = 6;
- list_op = CLUSTER_SUBTRACT;
- }
- else if (STRNICMP(rest, "contains", 8) == 0
- && (vim_iswhite(rest[8]) || rest[8] == '='))
- {
- opt_len = 8;
- list_op = CLUSTER_REPLACE;
- }
- else
- break;
-
- clstr_list = NULL;
- if (get_id_list(&rest, opt_len, &clstr_list) == FAIL)
- {
- EMSG2(_(e_invarg2), rest);
- break;
- }
- syn_combine_list(&SYN_CLSTR(curwin->w_s)[scl_id].scl_list,
- &clstr_list, list_op);
- got_clstr = TRUE;
+ scl_id = syn_check_cluster(arg, (int)(group_name_end - arg));
+
+ if (scl_id == 0)
+ {
+ EMSG((char_u *)_("Exxx: Too many syntax clusters"));
+ }
+ else
+ {
+ scl_id -= SYNID_CLUSTER;
+ for (;;)
+ {
+ if (STRNICMP(rest, "add", 3) == 0
+ && (vim_iswhite(rest[3]) || rest[3] == '='))
+ {
+ opt_len = 3;
+ list_op = CLUSTER_ADD;
+ }
+ else if (STRNICMP(rest, "remove", 6) == 0
+ && (vim_iswhite(rest[6]) || rest[6] == '='))
+ {
+ opt_len = 6;
+ list_op = CLUSTER_SUBTRACT;
+ }
+ else if (STRNICMP(rest, "contains", 8) == 0
+ && (vim_iswhite(rest[8]) || rest[8] == '='))
+ {
+ opt_len
Re: Vim crash with large xpm
Hi Ben, There are way too many syntax groups, and they overflow into syntax clusters, because clusters are stored in a high part of the syntax group id number-space, and Vim doesn't check it. The attached preliminary patch puts in a check for this and a couple of other possible syntax overflow conditions, so we should get errors, not crashes. It fixes this particular problem for me. An error occurs when the file is loaded, and scrolling is slow, but doesn't crash, and can be interrupted with control-C. Can others test this and confirm? Your patch prevents the crash for me. Also Vim starts up a lot quicker; it gives the "Exxx: Too many syntax groups" about ten seconds after starting Vim, where previously it would hang for about a minute before responding. - Peter Odding -- 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
Re: Re : tr() problem ?
On 11/02/11 11:02 PM, Dimitar DIMITROV wrote:
I just tested:
:com! Test ec '♛'
then
:Test prints ♀Q
:ec '♛' prints '♛'
So the problem is :com related not tr() as previously thought
Attached is the fix.
K_SPECIAL is not a multibyte character code, so vim_strchr is not an appropriate
way to search for it. A bytewise search of the string is needed.
Ben.
--
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
# HG changeset patch
# Parent 0032a84f560c4a5970cb3be1fa93d52ffe9f4d22
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -6072,8 +6072,10 @@
end = vim_strchr(start + 1, '>');
if (buf != NULL)
{
- ksp = vim_strchr(p, K_SPECIAL);
- if (ksp != NULL && (start == NULL || ksp < start || end == NULL)
+ ksp = p;
+ while (*ksp != NUL && *ksp != K_SPECIAL)
+ ++ksp;
+ if (*ksp == K_SPECIAL && (start == NULL || ksp < start || end == NULL)
&& ((ksp[1] == KS_SPECIAL && ksp[2] == KE_FILLER)
# ifdef FEAT_GUI
|| (ksp[1] == KS_EXTRA && ksp[2] == (int)KE_CSI)
Re: php.vim fixed, need help getting it applied
Please, can someone commit my patch? I'm pretty sure some of you have commit access. It's been almost 5 months since I submitted the patch. Thank you, - Jason -- 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
Re: php.vim fixed, need help getting it applied
Hi JasonWoof! On Mi, 02 Mär 2011, JasonWoof wrote: > Please, can someone commit my patch? > > I'm pretty sure some of you have commit access. Nobody but Bram has commit access. > > It's been almost 5 months since I submitted the patch. The question is, would you take maintainership of the syntax file? regards, Christian -- 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
[PATCH] foldexpr for help files
The following patch adds foldexpr option that will fold sections separated by
sequences of `=' (foldlevel=1) and `-' (foldlevel=2).
# HG changeset patch
# User ZyX
# Date 1299087044 -10800
# Node ID 8d0b25fb6467b5ab90699e485aee1ed6dec0c205
# Parent 0139403c8eb088d58773f7e76dc2a025719a8e8c
Added foldexpr for help files
diff -r 0139403c8eb0 -r 8d0b25fb6467 runtime/ftplugin/help.vim
--- a/runtime/ftplugin/help.vim Fri Feb 25 18:38:36 2011 +0100
+++ b/runtime/ftplugin/help.vim Wed Mar 02 20:30:44 2011 +0300
@@ -11,9 +11,16 @@
let s:cpo_save = &cpo
set cpo&vim
-let b:undo_ftplugin = "setl fo< tw< cole< cocu<"
+let b:undo_ftplugin = "setl fo< tw< cole< cocu< fdm< fde< fdt<"
-setlocal formatoptions+=tcroql textwidth=78 cole=2 cocu=nc
+setlocal formatoptions+=tcroql textwidth=78 cole=2 cocu=nc foldmethod=expr
+let &l:foldexpr="getline(v:lnum)=~#'^=\\{70,}$' ? 1 : ".
+\ "(getline(v:lnum+1)=~#'^=\\{70,}$' ? '<1' :".
+\ "(getline(v:lnum)=~#'^-\\{70,}$' ? 2 : ".
+\ "(getline(v:lnum+1)=~#'^-\\{70,}$' ? '<2' : ".
+\ "'=')))"
+let &l:foldtext="v:folddashes.substitute(getline(v:foldstart+1), ".
+\ "'\\v%( +\\*[^*]+\\*)* *$', '', '')"
let &cpo = s:cpo_save
unlet s:cpo_save
signature.asc
Description: This is a digitally signed message part.
Re: Vim crash with large xpm
Ben Schmidt wrote: > > I just tried the file. Opening Vim took about a minute with Vim > > running at 100% CPU after which Vim became responsive. I then scrolled > > down by repeating 99 and just before I reached the bitmap > > part of the XPM file Vim crashed. I've tried a few times and it > > crashes every time, but only after reaching the bitmap part. > > There are way too many syntax groups, and they overflow into syntax > clusters, because clusters are stored in a high part of the syntax group > id number-space, and Vim doesn't check it. > > The attached preliminary patch puts in a check for this and a couple of > other possible syntax overflow conditions, so we should get errors, not > crashes. > > It fixes this particular problem for me. An error occurs when the file > is loaded, and scrolling is slow, but doesn't crash, and can be > interrupted with control-C. > > Can others test this and confirm? > > Bram, if you're happy with this approach, I can tidy up the patch a bit, > i.e. put in error message numbers, including in the documentation, if > that's helpful. The checks for things going wrong are obviously good. I wonder if we can change the numbers without causing trouble. I don't think we ever thought of hitting these limits. On the other hand, allowing ridiculous numbers probably makes Vim run really slow, thus disallowing this might be better. Or we need to fix the slowness. -- Q: How many hardware engineers does it take to change a lightbulb? A: None. We'll fix it in software. /// Bram Moolenaar -- b...@moolenaar.net -- 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
Re: Re : tr() problem ?
Ben Schmidt wrote: > On 11/02/11 11:02 PM, Dimitar DIMITROV wrote: > > I just tested: > > > > :com! Test ec '♛' > > then > > :Test prints ♀Q > > :ec '♛' prints '♛' > > > > So the problem is :com related not tr() as previously thought > > Attached is the fix. > > K_SPECIAL is not a multibyte character code, so vim_strchr is not an > appropriate way to search for it. A bytewise search of the string is > needed. Thanks Ben! -- ARTHUR: Be quiet! DENNIS: Well you can't expect to wield supreme executive power just 'cause some watery tart threw a sword at you! ARTHUR: Shut up! DENNIS: I mean, if I went around sayin' I was an empereror just because some moistened bint had lobbed a scimitar at me they'd put me away! The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- b...@moolenaar.net -- 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
Re: Vim crash with large xpm
On 3/03/11 7:37 AM, Bram Moolenaar wrote: Ben Schmidt wrote: The attached preliminary patch puts in a check for this and a couple of other possible syntax overflow conditions, so we should get errors, not crashes. It fixes this particular problem for me. An error occurs when the file is loaded, and scrolling is slow, but doesn't crash, and can be interrupted with control-C. Can others test this and confirm? Bram, if you're happy with this approach, I can tidy up the patch a bit, i.e. put in error message numbers, including in the documentation, if that's helpful. The checks for things going wrong are obviously good. I wonder if we can change the numbers without causing trouble. I don't think we ever thought of hitting these limits. I think changing the numbers would just be a bigger job, but wouldn't really cause problems. At the moment the type for syntax ids is a short, so that would have to be changed throughout in order to increase the numbers. On the other hand, allowing ridiculous numbers probably makes Vim run really slow, thus disallowing this might be better. Or we need to fix the slowness. Probably by turning the grow arrays for syntax id lists into hash tables (probably pretty space inefficient?) or at least keeping them ordered and doing binary search (slow when manipulating syntax group lists, but quick otherwise--but would need special casing to keep ALLBUT, etc. at the front and deal with them appropriately, even though they have larger ids than normal syntax groups). One thing that probably should be changed somehow is having some way to reset running_syn_inc_id, which increases but has no way to be reset. A :syn clear or something should probably pull it back to zero. Ben. -- 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
Re: Patch 7.3.091
Hi, I'm observing the following bug under Ubuntu and FreeBSD, which
seems to have been introduced by this patch.
$ cd /tmp
$ seq 1 100 >file # bug happens with any sufficiently large file
$ echo 'set nocompatible foldmethod=marker lazyredraw' >vimrc
$ vim -u vimrc --noplugin file
vim doesn't display the file's contents until any key is pressed.
On Thu, Dec 30, 2010 at 14:31, Bram Moolenaar wrote:
>
> Patch 7.3.091
> Problem: "vim -w foo" writes special key codes for removed escape
> sequences. (Josh Triplett)
> Solution: Don't write K_IGNORE codes.
> Files: src/getchar.c, src/misc1.c, src/term.c, src/vim.h
>
>
> *** ../vim-7.3.090/src/getchar.c 2010-10-27 17:39:00.0 +0200
> --- src/getchar.c 2010-12-30 12:16:36.0 +0100
> ***
> *** 1506,1514
> }
> }
>
> - #define KL_PART_KEY -1 /* keylen value for incomplete
> key-code */
> - #define KL_PART_MAP -2 /* keylen value for incomplete
> mapping */
> -
> /*
> * Get the next input character.
> * Can return a special key or a multi-byte character.
> --- 1506,1511
> ***
> *** 2171,2177
> if (!timedout)
> {
> /* break at a partly match */
> ! keylen = KL_PART_MAP;
> break;
> }
> }
> --- 2168,2174
> if (!timedout)
> {
> /* break at a partly match */
> ! keylen = KEYLEN_PART_MAP;
> break;
> }
> }
> ***
> *** 2192,2198
>
> /* If no partly match found, use the longest full
> * match. */
> ! if (keylen != KL_PART_MAP)
> {
> mp = mp_match;
> keylen = mp_match_len;
> --- 2189,2195
>
> /* If no partly match found, use the longest full
> * match. */
> ! if (keylen != KEYLEN_PART_MAP)
> {
> mp = mp_match;
> keylen = mp_match_len;
> ***
> *** 2230,2236
> }
> /* Need more chars for partly match. */
> if (mlen == typebuf.tb_len)
> ! keylen = KL_PART_KEY;
> else if (max_mlen < mlen)
> /* no match, may have to check for termcode at
> * next character */
> --- 2227,2233
> }
> /* Need more chars for partly match. */
> if (mlen == typebuf.tb_len)
> ! keylen = KEYLEN_PART_KEY;
> else if (max_mlen < mlen)
> /* no match, may have to check for termcode at
> * next character */
> ***
> *** 2238,2244
> }
>
> if ((mp == NULL || max_mlen >= mp_match_len)
> ! && keylen != KL_PART_MAP)
> {
> int save_keylen = keylen;
>
> --- 2235,2241
> }
>
> if ((mp == NULL || max_mlen >= mp_match_len)
> ! && keylen != KEYLEN_PART_MAP)
> {
> int save_keylen = keylen;
>
> ***
> *** 2264,2271
> /* If no termcode matched but 'pastetoggle'
> * matched partially it's like an incomplete key
> * sequence. */
> ! if (keylen == 0 && save_keylen == KL_PART_KEY)
> ! keylen = KL_PART_KEY;
>
> /*
> * When getting a partial match, but the last
> --- 2261,2268
> /* If no termcode matched but 'pastetoggle'
> * matched partially it's like an incomplete key
> * sequence. */
> ! if (keylen == 0 && save_keylen == KEYLEN_PART_KEY)
> ! keylen = KEYLEN_PART_KEY;
>
> /*
> * When getting a partial match, but the last
> ***
> *** 2302,2308
>
Re: Patch 7.3.091
On Thu, Mar 03, 2011 at 09:26:47AM +0300, Ivan Krasilnikov wrote: > Hi, I'm observing the following bug under Ubuntu and FreeBSD, which > seems to have been introduced by this patch. > > $ cd /tmp > $ seq 1 100 >file # bug happens with any sufficiently large file > $ echo 'set nocompatible foldmethod=marker lazyredraw' >vimrc > $ vim -u vimrc --noplugin file > > vim doesn't display the file's contents until any key is pressed. It's in xterm with 256 colors support enabled, isn't it? I have the same problem. -- Kirill A. Shutemov -- 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
Re: Patch 7.3.091
On Thu, Mar 3, 2011 at 09:37, Kirill A. Shutemov wrote: > It's in xterm with 256 colors support enabled, isn't it? I have the same > problem. Right. It happens to me in Ubuntu's xterm, gnome-terminal, konsole, on a FreeBSD machine via ssh in these terminal emulators. But it doesn't happen when I start vim in Ubuntu's framebuffer console. -- 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
