Edgewall Software
Modify

Opened 15 years ago

Closed 15 years ago

#3862 closed defect (worksforme)

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

Reported by: trevor@… Owned by: Christian Boos
Priority: normal Milestone:
Component: version control Version: 0.10
Severity: major Keywords: svn140 solaris
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christian Boos)

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

Attachments (0)

Change History (8)

comment:1 by Christian Boos, 15 years ago

Component: generalversion control
Description: modified (diff)
Keywords: svn140 solaris added
Owner: changed from Jonas Borgström to Christopher Lenz
Severity: normalmajor

(some cleanups)

comment:2 by Christian Boos, 15 years ago

Owner: changed from Christopher Lenz to 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…

in reply to:  2 ; comment:3 by trevor@…, 15 years ago

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.

in reply to:  3 ; comment:4 by Christian Boos, 15 years ago

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…

in reply to:  4 comment:5 by trevor@…, 15 years ago

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?

in reply to:  3 comment:6 by trevor@…, 15 years ago

Resolution: fixed
Status: newclosed

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!

comment:7 by Christian Boos, 15 years ago

Resolution: fixed
Status: closedreopened

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

(reopening only to change the status)

comment:8 by Christian Boos, 15 years ago

Resolution: worksforme
Status: reopenedclosed

(fixed is reserved for tickets requiring actual code changes)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.