Le Tuesday 24 November 2009, à 02:03:44AM +0300, Сергей a écrit : 
> On Mon, Nov 23, 2009 at 11:54 PM, Colin Watson <[email protected]> wrote:
> > On Thu, Aug 13, 2009 at 01:45:47PM +0400, Sergey Yanovich wrote:
> >> After upgrading from 5.7-4 to 5.8-1 ctags produces tags file for
> >> mozilla source tree that vim considers corrupted:
> >>
> >> 1. get mozilla tree
> >>  hg clone http://hg.mozilla.org/releases/mozilla-1.9.1/ mozilla
> >>  cd mozilla
> >
> > Can you provide a smaller test case, please? My Internet connection is
> > rather slow, and I don't want to download a large package like this if I
> > can avoid it.
> 
> Vim says corruption happens at byte 24245178. It points to a file
> content/canvas/test/test_2d.line.cross.html. If I run ctags on a
> subfolder 'content', corruption is not present.
> 
> In addtion, when I opened the tags file in vim, I noticed that vim
> converts it to display. When I save the converted file, corruption is
> not present either.
> 
> So, it looks like it takes the whole tree to reproduce the bug.

Hi,
I can reproduce the bug with mozilla tree.
I investigated more, and I discovered the bug comes probably from vim not
being able to read long ctag lines (ctags 5.8 now parses javascript objects
properties, which result in long lines being produced for mozilla tree)

Here is a copy of the mail I sent to [email protected]
Hi,
vim fails to parse tags produced by ctags for mozilla tree. This bug had been
reported on ctags bugtracker:

http://sourceforge.net/tracker/index.php?func=detail&aid=2836814&group_id=6556&atid=106556

To summarize, when trying to use tag file produced for mozilla tree, vim
sometimes fail. This happen for ctags 5.8, but did not happen for ctags 5.7.

But I investigated, and that since 5.8, ctags handles objects with literal and
properties in Javascript. Then, ctags produces long lines in some cases on
mozilla tree.

for example, this file
http://mxr.mozilla.org/mozilla-central/source/dom/src/json/test/unit/test_decode_long_input.js
produces a tag file containing this line:

x.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
      /home/arno/mozilla/dom/src/json/test/unit/test_decode_long_input.js     
/^"17Lorem ipsum his ponderum delicatissimi ne, at noster dolores urbanitas 
pro, cibo elaboraret no his. Ea dicunt maiorum usu. Ad appareat facilisis 
mediocritatem eos. Tale graeci mentitum in eos, hinc insolens at nam. Graecis 
nominavi aliquyam eu vix.":"Id solet assentior sadipscing pro. Et per atqui 
graecis, usu quot viris repudiandae ei, mollis evertitur an nam. At nam dolor 
ignota, liber labore omnesque ea mei, has movet voluptaria in. Vel an impetus 
omittantur. Vim movet option salutandi ex, ne mei ignota corrumpit. Mucius 
comprehensam id per. Est ea putant maiestatis.",$/;"     p

This is valid, but not handled correctly by vim.
When using tselect, vim will fail with following error:

E431: Format error in tags file "tags"                                          
                                                   
Before byte 16914
E426: tag not found:

Note that the bug is not encountered every time. I suppose this is because the
binary search may, in some case, not read the problematic line.

I investigated, more, and discovered the root of the problem in src/tag.c:
only LSIZE (512) buffers are read into lbuf; then 
tagp.tagname_end = vim_strchr(lbuf, TAB);
will return NULL, and the file will be considered corrupted.

I'll attach a fix proposal

arno
diff -r 749c0a60b745 src/tag.c
--- a/src/tag.c Thu Dec 01 20:59:21 2011 +0100
+++ b/src/tag.c Wed Dec 07 18:18:38 2011 +0100
@@ -1907,18 +1907,30 @@ line_read_in:
 #ifdef FEAT_TAG_ANYWHITE
                tagp.tagname_end = skiptowhite(lbuf);
                if (*tagp.tagname_end == NUL)       /* corrupted tag line */
 #else
                tagp.tagname_end = vim_strchr(lbuf, TAB);
                if (tagp.tagname_end == NULL)       /* corrupted tag line */
 #endif
                {
-                   line_error = TRUE;
-                   break;
+                   if (vim_strchr(lbuf, LF) == NULL)
+                   {
+                       /* Truncated line.  Ignore it. */
+                       if (p_verbose >= 5)
+                       {
+                           verbose_enter();
+                           MSG(_("Ignoring long line in tags file"));
+                           verbose_leave();
+                       }
+                       continue;
+                    } else {
+                       line_error = TRUE;
+                        break;
+                    }
                }
 
 #ifdef FEAT_TAG_OLDSTATIC
                /*
                 * Check for old style static tag: "file:tag file .."
                 */
                tagp.fname = NULL;
                for (p = lbuf; p < tagp.tagname_end; ++p)

Reply via email to