Reproducible svn assertion that crashes server (Apache/standalone tracd)

[allarddijk]

8 months ago reported to Bitten. But it seems a Trac bug after investigation : ​http://bitten.edgewall.org/ticket/525

Actions to reproduce for Trac: dfraser found:

{ echo 'GET /trac/browser/. HTTP/1.0' ; echo ; } | telnet localhost 8001

Apache service crashes (SVN module crashes according to Apache log) ⇒ python: subversion/libsvn_subr/path.c:115: svn_path_join: Assertion `svn_path_is_canonical(component, pool)' failed.

Running on: Apache/2.2.9(Win32) SVN/1.5.2 mod_python/3.3.1 Python/2.5.2 mod_auth_sspi/1.0.4 DAV/2 Server. Trac 0.11.6

[dfraser]

Traceback to where the crash occurs is something like this:

  trac/versioncontrol/cache.py(235)get_node()
-> return self.repos.get_node(path, rev)
  trac/versioncontrol/svn_fs.py(438)get_node()
-> return SubversionNode(path, rev, self, self.pool)
> trac/versioncontrol/svn_fs.py(672)__init__()
-> node_type = fs.check_path(self.root, self._scoped_path_utf8, pool)

At this point, self._scoped_path_utf8 is '.'

It seems insane to me that the fs.check_path crashes with an assertion error here.

I can't see anything in versioncontrol/api.py that would allow us to easily prevent this.

NB trying this with Firefox or wget to the URL mentioned above fails as it seems to internally reform it and remove the trailing . before passing it on.

Bumping the priority here but if I'm out of place to do that feel free to bump it down again.

[Christian Boos]

Replying to dfraser:

At this point, self._scoped_path_utf8 is '.'

Thanks, this should effectively not happen, we should really prevent this. Anything special in your setup? E.g. where's the actual repository directory and how is it specified in Trac? Was it specified with [trac] repository_dir (the default repository) or by using [repositories], or was it created via trac-admin or the web admin? What's the output of trac-admin <env> repository list?

It seems insane to me that the fs.check_path crashes with an assertion error here.

Well, this has been debated a lot on the Subversion mailing list in the last decade, the conclusion was always to blame the API users for their misuse. It doesn't disturb them too much to abort like that ;-)

Bumping the priority here but if I'm out of place to do that feel free to bump it down again.

It's fair game.

[Remy Blank]

FWIW, I can't reproduce this on Linux, so it could be Windows-specific.

[Remy Blank]

I still can't reproduce this on Windows 7, Python 2.6.4, svn-python-1.6.6. I get a standard 404.

However, for some reason, I can now reproduce it on Linux, Python 2.6.5, svn-1.6.12. So, definitely not Windows-specific.

[Remy Blank]

Canonicalize paths before passing them to Subversion.

[Remy Blank]

9626-canonicalize-r10116.patch​ fixes the issue for me. Testing welcome.

[Remy Blank]

The patch has been tested successfully on Linux (Python 2.6 + SVN 1.6.12), OS X (Python 2.6 + SVN 1.6.12, Python 2.4 + SVN 1.6.9), Windows 7 (Python 2.6 + SVN 1.6.6).

OTOH, I don't have SVN 1.5.x anymore. Christian, do you happen to still have that lying around?

[osimons]

Works for Linux + Subversion 1.5.7 for me. Before the process died, now response is returned.

[Christian Boos]

Replying to rblank:

.. do you happen to still have that lying around?

Yep, now in f.e.o/tmp/win.

[Remy Blank]

Thanks for testing, Simon!

Replying to cboos:

Yep, now in f.e.o/tmp/win.

Heh, I meant "a working environment with SVN 1.5.x, do to a quick test of the patch" :)

Anyway, Linux seems to be fine, and I'll do a quick check on Windows with SVN 1.5.

[Remy Blank]

Replying to rblank:

and I'll do a quick check on Windows with SVN 1.5.

Argh, we run the svnadmin command-line program to create the repository in the test suite, and I couldn't find an installer for that :(

Anyway, I have checked the signature of svn_path_canonicalize(), and it's the same between 1.5.5 and 1.6 (I don't expect it to have changed much). And Simon has tested on 1.5.7, so I don't expect any breakage depending on the platform.

Patch applied in [10125].