Subversion 1.4.0 error: Final line in revision file longer than 64 characters

[trevor@…]

Attempting to upgrade Subversion 1.3.2 to version 1.4.0 has broken my Trac system on Solaris 10. When browsing source for any Trac instance the following error is thrown:

Traceback (most recent call last):
  File "/opt/local/lib/python2.4/site-packages/trac/web/main.py", line 335, in dispatch_request
    dispatcher.dispatch(req)
  File "/opt/local/lib/python2.4/site-packages/trac/web/main.py", line 220, in dispatch
    resp = chosen_handler.process_request(req)
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/web_ui/browser.py", line 100, in process_request
    rev_or_latest = rev or repos.youngest_rev
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 144, in <lambda>
    youngest_rev = property(lambda x: x.get_youngest_rev())
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/cache.py", line 123, in get_youngest_rev
    return self.repos.youngest_rev
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 144, in <lambda>
    youngest_rev = property(lambda x: x.get_youngest_rev())
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 383, in get_youngest_rev
    for path, rev in self._history('', 0, self.youngest, limit=1):
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 89, in _get_history
    start, end, 1, pool())
  File "/usr/local/lib/svn-python/libsvn/repos.py", line 291, in svn_repos_history2
    return apply(_repos.svn_repos_history2, args)
SubversionException: ('Final line in revision file longer than 64 characters', 160004)

In the Subversion source file libsvn_fs_fs/fs_fs.c function get_root_changes_offset(), if the line:

      return svn_error_createf(SVN_ERR_FS_CORRUPT, NULL,
                               _("Final line in revision file longer than 64 "
                                 "characters"));

is replaced with:

      return svn_error_createf(SVN_ERR_FS_CORRUPT, NULL,
                               _(buf));

The error changes to:

Traceback (most recent call last):
  File "/opt/local/lib/python2.4/site-packages/trac/web/main.py", line 335, in dispatch_request
    dispatcher.dispatch(req)
  File "/opt/local/lib/python2.4/site-packages/trac/web/main.py", line 220, in dispatch
    resp = chosen_handler.process_request(req)
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/web_ui/browser.py", line 100, in process_request
    rev_or_latest = rev or repos.youngest_rev
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 144, in <lambda>
    youngest_rev = property(lambda x: x.get_youngest_rev())
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/cache.py", line 123, in get_youngest_rev
    return self.repos.youngest_rev
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 144, in <lambda>
    youngest_rev = property(lambda x: x.get_youngest_rev())
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 383, in get_youngest_rev
    for path, rev in self._history('', 0, self.youngest, limit=1):
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 89, in _get_history
    start, end, 1, pool())
  File "/usr/local/lib/svn-python/libsvn/repos.py", line 291, in svn_repos_history2
    return apply(_repos.svn_repos_history2, args)
SubversionException: ('\n', 160004)

If the error check is commented out completely this is thrown instead:

Traceback (most recent call last):
  File "/opt/local/lib/python2.4/site-packages/trac/web/main.py", line 356, in dispatch_request
    dispatcher.dispatch(req)
  File "/opt/local/lib/python2.4/site-packages/trac/web/main.py", line 224, in dispatch
    resp = chosen_handler.process_request(req)
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/web_ui/browser.py", line 100, in process_request
    rev_or_latest = rev or repos.youngest_rev
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 144, in <lambda>
    youngest_rev = property(lambda x: x.get_youngest_rev())
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/cache.py", line 123, in get_youngest_rev
    return self.repos.youngest_rev
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 144, in <lambda>
    youngest_rev = property(lambda x: x.get_youngest_rev())
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 383, in get_youngest_rev
    for path, rev in self._history('', 0, self.youngest, limit=1):
  File "/opt/local/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 89, in _get_history
    start, end, 1, pool())
  File "/usr/local/lib/svn-python/libsvn/repos.py", line 291, in svn_repos_history2
    return apply(_repos.svn_repos_history2, args)
SubversionException: ('Found malformed header in revision file', 160004)

Is this an error with Subversion instead of Trac? Subversion seems to be working just fine otherwise. I can only generate the error via Trac - unless perhaps someone has some tricks to try.

Thanks for your help,

Trevor Wennblom

[Christian Boos]

(some cleanups)

[Christian Boos]

Try to insert some print statements in the authz_cb and history2_cb (see below source:tags/trac-0.10/trac/versioncontrol/svn_fs.py@#L76​). Do we even get there?

It would be interesting to locate the "faulty" rev, and then see if you can access that revision specifically (like get an incremental dump of it).

I know that it is possible to have a repos which "looks" fine and which you're able to work with, but is actually corrupt at one point in the history…

[trevor@…]

Replying to cboos:

Try to insert some print statements in the authz_cb and history2_cb (see below source:tags/trac-0.10/trac/versioncontrol/svn_fs.py@#L76​). Do we even get there?

Changed the Trac source in svn_fs.py to:

    if hasattr(repos, 'svn_repos_history2'):
        # For Subversion >= 1.1
        def authz_cb(root, path, pool):
            print "p1"
            if limit and len(history) >= limit:
                return 0
            print "p2"
            return authz.has_permission(_from_svn(path)) and 1 or 0
        print "p3"
        def history2_cb(path, rev, pool):
            print "p4"
            history.append((_from_svn(path), rev))
            print "p5"
        print "p6"
        repos.svn_repos_history2(fs_ptr, svn_path, history2_cb, authz_cb,
                                 start, end, 1, pool())
        print "p7"

And tracd reports the following:

p3
p6

So it doesn't appear that the authz_cb and history2_cb methods are being called.

It would be interesting to locate the "faulty" rev, and then see if you can access that revision specifically (like get an incremental dump of it).

This is a brand new repository as of a few weeks with roughly 40 revisions. Any idea how I could poke at it with Trac to see if a specific revision is faulty? Subversion still seems to think it's fine from the command-line with commits and checkouts.

[Christian Boos]

Replying to trevor@corevx.com:

… This is a brand new repository as of a few weeks with roughly 40 revisions. Any idea how I could poke at it with Trac to see if a specific revision is faulty?

Try to do a full dump, then (svnadmin dump path_to_your_svn_repos), but it doesn't look like it's actually corrupted. It's more probably an issue with the bindings, given the debug output you had…

[trevor@…]

Replying to cboos:

Try to do a full dump, then (svnadmin dump path_to_your_svn_repos), but it doesn't look like it's actually corrupted. It's more probably an issue with the bindings, given the debug output you had…

$ svnadmin dump /myrepos/svn/repos/ > foo

• Dumped revision 0.
• Dumped revision 1.
• Dumped revision 2.

…

• Dumped revision 45.
• Dumped revision 46.
• Dumped revision 47.

$

Looks ok?

[trevor@…]

Fixed -

In the new Subversion install make swig-py and make install-swig-py did the trick - you were correct about the bindings.

Thanks for the help!

[Christian Boos]

Ok, great, so IIUC, you used the 1.3.2 bindings with a 1.4.0 repos, right?

(reopening only to change the status)

[Christian Boos]

(fixed is reserved for tickets requiring actual code changes)