Getting UnicodeDecodeError when svn enabled

[jn534@…]

Environment:

Trac:	0.11.2.1
Python:	2.5.2
Subversion:	1.4.3
ModPython:	3.3.1
Apache:	2.2.6

When I enable the subversion module (by adding the appropriate svn-python path to my PythonPath variable) I get the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/web/api.py", line 367, in send_error
    'text/html')
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/web/chrome.py", line 719, in render_template
    return stream.render(method, doctype=doctype)
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/core.py", line 179, in render
    return encode(generator, method=method, encoding=encoding, out=out)
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/output.py", line 60, in encode
    return _encode(u''.join(list(iterator)))
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/output.py", line 311, in __call__
    for kind, data, pos in stream:
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/output.py", line 753, in __call__
    for kind, data, pos in stream:
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/output.py", line 592, in __call__
    for kind, data, pos in stream:
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/output.py", line 707, in __call__
    text = mjoin(textbuf, escape_quotes=False)
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/core.py", line 465, in join
    for item in seq]))
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/core.py", line 494, in escape
    text = unicode(text).replace('&', '&') \
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa3 in position 1684: ordinal not in range(128)

When attempting to change to UTF-8 encoding in site.py it doesn't improve much:

Traceback (most recent call last):
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/web/api.py", line 367, in send_error
    'text/html')
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/web/chrome.py", line 719, in render_template
    return stream.render(method, doctype=doctype)
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/core.py", line 179, in render
    return encode(generator, method=method, encoding=encoding, out=out)
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/output.py", line 60, in encode
    return _encode(u''.join(list(iterator)))
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/output.py", line 311, in __call__
    for kind, data, pos in stream:
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/output.py", line 753, in __call__
    for kind, data, pos in stream:
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/output.py", line 592, in __call__
    for kind, data, pos in stream:
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/output.py", line 707, in __call__
    text = mjoin(textbuf, escape_quotes=False)
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/core.py", line 465, in join
    for item in seq]))
  File "/usr/local/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686.egg/genshi/core.py", line 494, in escape
    text = unicode(text).replace('&', '&') \
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa3 in position 1684: unexpected code byte

Ideas on how to convince trac to use my svn repository?

[Christian Boos]

Please have a look at comment:8:ticket:7959, is it the same issue?

[jn534@…]

I have only ascii characters in my svn repository path names. So far as I know there are no non-ascii characters in any of the text source files either (though there are binary files such as jpgs and pngs in the repository). This does not appear to be the issue described in this comment (though perhaps the cure might be similar).

[Christian Boos]

Just to be sure we're talking about the same thing, are you sure that the repository_dir (i.e. the location of the SVN repository itself) doesn't contain non-ascii characters?

Also, for which URL do you get this error?

[jn534@…]

I upgraded to svn 1.5.5 today, restarted everything, and no longer get this error. Might be worth a note in the wiki but my issue is now resolved.

None of my repository paths get this error. I was getting this error for all URIs not just for browsing within the code tree.

[Christian Boos]

I wonder if you tried to access an upgraded 1.5 repository with the 1.4.3 bindings… Then the bindings could have triggered an exception with some non-unicode message (which locale do you use?), and that would have triggered the error. I would be interested if you could post the relevant backtrace from the trac.log, if you can find it.

[jn534@…]

Everything was (as far as svn was concerned) 1.4.3 yesterday. Below is (I believe) the trac.log entries for any of the UI queries that you are looking for. Let me know if this helps or if there is something else you require.

2009-01-27 19:27:02,889 Trac[perm] DEBUG: No policy allowed anonymous performing TRAC_ADMIN on None
2009-01-27 19:27:02,889 Trac[chrome] DEBUG: Prepare chrome data for request
2009-01-27 19:27:02,892 Trac[perm] DEBUG: No policy allowed anonymous performing BROWSER_VIEW on None
2009-01-27 19:27:02,893 Trac[perm] DEBUG: No policy allowed anonymous performing PERMISSION_GRANT on None
2009-01-27 19:27:02,893 Trac[perm] DEBUG: No policy allowed anonymous performing PERMISSION_REVOKE on None
2009-01-27 19:27:02,894 Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on None
2009-01-27 19:27:02,898 Trac[perm] DEBUG: No policy allowed anonymous performing EMAIL_VIEW on None
2009-01-27 19:27:02,974 Trac[main] DEBUG: 369 unreachable objects found.
2009-01-27 19:34:29,140 Trac[main] DEBUG: Dispatching <Request "GET u'/ticket/190'">
2009-01-27 19:34:29,142 Trac[main] ERROR: argument number 1: a 'apr_pool_t *' is expected, 'PySwigObject(<A3><D8><87>^C<B1><D8><87>^C)' is received
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/web/main.py", line 432, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/web/main.py", line 174, in dispatch
    chosen_handler)
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/web/main.py", line 295, in _pre_process_request
    chosen_handler = filter_.pre_process_request(req, chosen_handler)
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/versioncontrol/api.py", line 86, in pre_process_request
    self.get_repository(req.authname).sync()
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/versioncontrol/api.py", line 157, in get_repository
    repos = self._connector.get_repository(rtype, rdir, authname)
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/versioncontrol/svn_fs.py", line 280, in get_repository
    'branches': self.branches})
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/versioncontrol/svn_fs.py", line 390, in __init__
    self.pool = Pool()
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/versioncontrol/svn_fs.py", line 151, in __init__
    self._pool = core.svn_pool_create(self._parent_pool())
  File "/usr/local/lib/svn-python/svn/core.py", line 177, in svn_pool_create
    return Pool(parent_pool)
  File "/usr/local/lib/svn-python/libsvn/core.py", line 1137, in svn_pool_create
    return apply(_core.svn_pool_create, args)
TypeError: argument number 1: a 'apr_pool_t *' is expected, 'PySwigObject(<A3><D8><87>^C<B1><D8><87>^C)' is received

[Christian Boos]

That's perfect, thanks!

Let's see if this needs a separate fix or if this will be part of #7935.

[Christian Boos]

Yes, this problem should now be fixed by the same set of changes that were related to #7935.