Internal error while accessing Timeline page.

[mot at tdvniikp dot ru]

Sometimes (i can not say how often/what it depends on) i get this error while accessing Timeline:

Trac detected an internal error: 
argument to += must be iterable

Python traceback

Traceback (most recent call last):
  File "c:\python23\lib\site-packages\trac\web\modpython_frontend.py", line 206, in handler
    dispatch_request(mpr.path_info, mpr, env)
  File "C:\Python23\lib\site-packages\trac\web\main.py", line 139, in dispatch_request
    dispatcher.dispatch(req)
  File "C:\Python23\lib\site-packages\trac\web\main.py", line 107, in dispatch
    resp = chosen_handler.process_request(req)
  File "C:\Python23\lib\site-packages\trac\Timeline.py", line 140, in process_request
    filters)
TypeError: argument to += must be iterable

Platform is Windows2000/Apache 2.0.55.

Python is used by mod_python 3.2.8.

[mot at tdvniikp dot ru]

I've understood why this error takes place.

I've first Trac location on first virtualhost, and few days ago i've added second Trac on second virtualhost in Apache. And if someone is working simultaneously in this two locations we have this error.

Config of my Apache:

<VirtualHost 123.123.123.123>  	
	ServerName trac.first.ru	

	DocumentRoot "e:/wwwroot/first/trac"

	<Location /trac>
		SetHandler mod_python
		PythonHandler trac.web.modpython_frontend
		PythonOption TracEnvParentDir e:/wwwroot/first/trac
		PythonOption TracUriRoot /trac
		PythonOption PYTHON_EGG_CACHE e:/temp

		AuthType Basic
		AuthName "Trac"
		AuthUserFile e:/wwwroot/first/trac/.htpasswd
		Require valid-user
	</Location>

	<Location /svn>
		DAV svn
		SVNPath e:/wwwroot/svn/first
		AuthType Basic
		AuthName "Subversion repository"
		AuthUserFile e:/wwwroot/first/trac/.htpasswd
		Require valid-user
	</Location>	
</VirtualHost>

<VirtualHost 123.123.123.124>
	ServerName trac.second.ru

	DocumentRoot "e:/wwwroot/second/trac"

	<Location /trac>
		SetHandler mod_python
		PythonHandler trac.web.modpython_frontend 
		PythonOption TracEnvParentDir e:/wwwroot/second/trac
		PythonOption TracUriRoot /trac		
		PythonOption PYTHON_EGG_CACHE e:/temp

		AuthType Basic
		AuthName "Trac"
		AuthUserFile e:/wwwroot/second/trac/.htpasswd
		Require valid-user
	</Location>
</VirtualHost>

[mot at tdvniikp dot ru]

Problem fixed by downgrading from Subversion 1.3 to 1.2.3, correspondingly changing Subversion python bindings to 1.2.3.

[Christian Boos]

Okay, AFAIK, there's no widely available Subversion 1.3 bindings

for Python 2.3 on Windows…

So you had that issue because the bindings were not loaded.

I'll take a look if we can produce a better error message.

[mot at tdvniikp dot ru]

There are widely available Subversion 1.3 bindings. You can download it from Subversion main web site: ​here

And, by the way, if bindings were not loaded i would never can be use Trac. But i used it on single virtualhost for a long time.

[Christian Boos]

Ah, yes. Sorry, I thought those binaries were compiled for 2.4, but you're right, they're for 2.3.

(I'm using my own ones, which I compiled for 2.4 a long time ago, hence the confusion…)

[vdenisov@…]

Followup from ticket 3039.

My setup is definitely very similar to the one in 2965 - I'm using Apache with 2 virtual hosts for two different Trac projects, as well as for hosting some PHP-based applications. But setup was rock solid for the past 2 or 3 months, with Trac (and Python 2.3 via CGI) being present (and heavily used) for the past 1.5 month.

Initially, only one Trac project was set up on this box, and I've added another one about a week ago. This one also saw quite heavy usage, I've started seeing errors when loading images and CSS, etc. From the information here I'd come to the conclusion that Windows wasn't fast enough in getting enough processes "in the air" for CGI, and so decided to move to mod_python. Its worth noting that the project was used for about 3 days without crashes (and now I see them about every 2 (working) hours), so its unlikely that this problem was present in CGI mode.

I'm using basic auth via .htpasswd.

Apache had just crashed on one of my developers again (btw, on another project this time) - and the log file shows a somewhat different error from the first case. I'll attach a relevant portion of the log right after this message.

Looking at the log, I'm more or less positive that this error is somehow related to Trac ↔ Subversion interaction… Weird… I'll see if I can try the version you've mentioned, and provide more information. Also, since I can't stop either project, I'll try to run them in different Apache instances, and if this will cause a problem as well. Unfortunately, I can't downgrade Subversion, which is of version 1.3.1 w/ appropriate Python bindings, as far as I know.

Regards, Victor Denisov.

[vdenisov@…]

Trac log file related to the Apache crash

[vdenisov@…]

Oops, accidentally uploaded complete log, instead of the relevant portion…

[vdenisov@…]

Ok, I can confirm that this problem is quite reliably reproduced by hitting timeline in both projects at (about) the same time. Apache crashes almost 100% of the time…

[anonymous]

Setting up one of the two Trac hosts in another Apache instance on the same machine seems to solve the problem. So, definitely a threading issue in either mod_python, Python itself or Subversion… Any idea who I should go bother next?

[Christian Boos]

Looking at the attachment:trac.2.log​, it seems that you're hit by the issue #2611. Have a look there and in TracSubversion#TracandSubversion1.3.0.

The bad thing is that you appear to have 1.3.1, which should already contain the fix …

[vdenisov@…]

Ok, I've read through both links… I'll try to apply the patch mentioned in 2611, and will report back. Also, is there anything else I can do to help solve this problem? Or should I wait for next SVN and/or Python and/or Trac release?

[Emmanuel Blot]

#3553 has been marked as a duplicate.

[daybreaker12@…]

Sometimes it produces another error message:

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/modpython_frontend.py", line 206, in handler
    dispatch_request(mpr.path_info, mpr, env)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 107, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.3/site-packages/trac/Timeline.py", line 140, in process_request
    filters)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/web_ui/changeset.py", line 108, in get_timeline_events
    repos = self.env.get_repository()
  File "/usr/lib/python2.3/site-packages/trac/env.py", line 155, in get_repository
    from trac.versioncontrol.svn_fs import SubversionRepository
ImportError: cannot import name SubversionRepository

[trac@…]

Updated to SVN 1.4.0 with Trac 0.10b1.

Mutliple virtual hosts (still) cause Apache to act very badly. Ugh. Back to SVN 1.3.2 + Python bindings 1.2.3. This is a Subversion problem, isn't it?

Platform: Windows XP with Apache 2.0: Apache/2.0.55 (Win32) DAV/2 mod_python/3.2.10 Python/2.4.3 mod_ssl/2.0.55 OpenSSL/0.9.8a SVN/1.4.0

[Christian Boos]

Replying to trac@digidescorp.com:

Mutliple virtual hosts (still) cause Apache to act very badly. Ugh. Back to SVN 1.3.2 + Python bindings 1.2.3. This is a Subversion problem, isn't it?

This is a Subversion Python binding problem actually, but there's now a documented workaround for the issue, see TracSubversion#TracandSubversion1.3.1.

[trac@…]

OK, thanks. That works nicely enough, I guess.

[Christian Boos]

Same as #2611. This ticket helped to discover the role of multiple vhosts (and hence multiple python interpreters) in this problem.

[barrel_123456@…]

sir i have internal error#2 problem when i open any keygen sir pl help me sir