RuntimeError: instance.__dict__ not accessible in restricted mode

[kjvdbent]

How to Reproduce

While doing a GET operation on /ticket/.assembla.com/pepperflow/ticket/1098, Trac issued an internal error.

(please provide additional details here)

User Agent was: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.904.0 Safari/535.7

System Information

Trac	0.11.7
Python	2.6.6 (r266:84292, Dec 26 2010, 22:48:11) [GCC 4.4.5]
setuptools	0.6
SQLite	3.7.3
pysqlite	2.4.1
Genshi	0.6
mod_wsgi	3.3 (WSGIProcessGroup WSGIApplicationGroup %{GLOBAL})
Pygments	1.3.1
jQuery:	1.2.6

Python Traceback

Traceback (most recent call last):
  File "/usr/local/breakout-rest-auth/eggs/Trac-0.11.7-py2.6.egg/trac/web/main.py", line 450, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/local/breakout-rest-auth/eggs/Trac-0.11.7-py2.6.egg/trac/web/main.py", line 176, in dispatch
    chosen_handler)
  File "/usr/local/breakout-rest-auth/eggs/Trac-0.11.7-py2.6.egg/trac/web/main.py", line 296, in _pre_process_request
    chosen_handler = filter_.pre_process_request(req, chosen_handler)
  File "/usr/local/breakout-rest-auth/eggs/Trac-0.11.7-py2.6.egg/trac/versioncontrol/api.py", line 86, in pre_process_request
    self.get_repository(req.authname).sync()
  File "/usr/local/breakout-rest-auth/eggs/Trac-0.11.7-py2.6.egg/trac/versioncontrol/api.py", line 132, in get_repository
    for connector in self.connectors
  File "/usr/local/breakout-rest-auth/eggs/Trac-0.11.7-py2.6.egg/trac/core.py", line 70, in extensions
    return filter(None, [component.compmgr[cls] for cls in extensions])
  File "/usr/local/breakout-rest-auth/eggs/Trac-0.11.7-py2.6.egg/trac/core.py", line 207, in __getitem__
    component = cls(self)
  File "/usr/local/breakout-rest-auth/eggs/Trac-0.11.7-py2.6.egg/trac/core.py", line 111, in maybe_init
    init(self)
  File "/usr/local/breakout-rest-auth/eggs/Trac-0.11.7-py2.6.egg/trac/versioncontrol/svn_fs.py", line 266, in __init__
    Pool()
  File "/usr/local/breakout-rest-auth/eggs/Trac-0.11.7-py2.6.egg/trac/versioncontrol/svn_fs.py", line 156, in __init__
    self._pool = core.svn_pool_create(self._parent_pool())
  File "/usr/lib/pymodules/python2.6/svn/core.py", line 241, in svn_pool_create
    return Pool(parent_pool)
  File "/usr/lib/pymodules/python2.6/libsvn/core.py", line 1572, in svn_pool_create
    return _core.svn_pool_create(*args)
  File "/usr/lib/pymodules/python2.6/libsvn/core.py", line 5658, in _wrap
    obj.set_parent_pool(self)
  File "/usr/lib/pymodules/python2.6/libsvn/core.py", line 5571, in set_parent_pool
    self._parent_pool = parent_pool or application_pool
  File "/usr/lib/pymodules/python2.6/libsvn/core.py", line 5559, in <lambda>
    __setattr__ = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value)
  File "/usr/lib/pymodules/python2.6/libsvn/core.py", line 44, in _swig_setattr
    return _swig_setattr_nondynamic(self,class_type,name,value,0)
  File "/usr/lib/pymodules/python2.6/libsvn/core.py", line 39, in _swig_setattr_nondynamic
    self.__dict__[name] = value
RuntimeError: instance.__dict__ not accessible in restricted mode

[Christian Boos]

Ouch…

This is not supposed to happen, using WSGIApplicationGroup %{GLOBAL} is supposed to avoid that bug (#3371). Anything special in your setup? Which Subversion verrsion is this?

[anonymous]

This is the Assembla version of TRAC. Apparently, they somehow directed me to the TRAC-site for issuing a bug instead of their own. To be realy honest I think the problem is more Assembla-related than TRAC… I'll try to file an issue on their site.

[Christian Boos]

No, it's fine to fill it here as well, as it seems the installation guidelines we give in TracModWSGI related to WSGIApplicationGroup and Subversion are not always true.

It would be nice if the Assembla guys could give a few more details about their setup here… Maybe the issue comes from the interaction with mod_python running in the same process (used also with the svn bindings, but for some other application?).

Graham, I hope you don't mind my adding you to the CC:. If you have a clue to share, it would be very welcome!

[graham.dumpleton@…]

Is there any way they can verify which interpreter they are running in?

​http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used

[Christian Boos]

Yes, that's the information we dump in the semi-automated bug report, see the #SystemInformation above. This information was gathered by this code: tags/trac-0.11.7/trac/web/main.py#L398​ (I see now that we miss an or '%{GLOBAL}' for WSGIProcessGroup value).

So here:

mod_wsgi

3.3 (WSGIProcessGroup WSGIApplicationGroup %{GLOBAL})

[kron82@…]

Hello, I'm guy from assembla. We use stable (squeeze) debian and modwsgi from debian packages

Here is config from apache

WSGIPassAuthorization On
WSGIScriptAlias / /etc/apache2/breakout/rest/modwsgi/atl-fs5-trac_hg.wsgi
WSGIImportScript /etc/apache2/breakout/rest/modwsgi/atl-fs5-trac_hg.wsgi process-group=%{GLOBAL} application-group=%{GLOBAL}

<Directory /etc/apache2/breakout/rest/modwsgi>
  WSGIApplicationGroup %{GLOBAL}
  Order deny,allow
  Allow from all
</Directory>

So basically I used many possibilities to force trac to use %{GLOBAL} interpreter as described here in documentation. atl-fs5-trac_hg.wsgi is just our wrapper around trac to do authentication.

On that given server we don't have trac instances that serves trac with svn, so I disabled it in trac.ini

[components]
trac.versioncontrol.svn_fs.* = disabled

And tricks with %{GLOBAL} didn't helped until I disabled svn.

Software versions:

libapache2-mod-wsgi                 3.3-2
python                              2.6.6-3+squeeze6
apache2                             2.2.19-1
trac 0.11.7    from egg

[Christian Boos]

Wild guess: could an Apache child process end up serving more than this Trac installation? (e.g. Trac in different virtual hosts)? And one of these other installation is not configured to use WSGIApplicationGroup %{GLOBAL}?

[Christian Boos]

… or another application using the Python bindings for svn, like viewvc (see ticket:3371#comment:80)

[kron82@…]

Yes it could, on this server we have two trac vhosts, one for git and one for mercurial. I worked with mercurial.

Now I've configured both vhosts to use %{GLOBAL} interpreter as I described above and enabled svn back. Trac started to give same error as described topic starter.

[kron82@…]

Also, there is no viewvc, but on the same apache/mod_wsgi we use WSGIAccessScript/WSGIAuthGroupScript/WSGIAuthUserScript with separate application-group=auth

[Graham.Dumpleton@…]

But do you access anything Trac related in the AAA scripts?

[kron82@…]

No, definitely no.

[Christian Boos]

A crude way to get some more hints about what's going on is to add some debugging code directly into /usr/lib/pymodules/python2.6/libsvn/core.py!

I suggest that you add near line 5571 (in apr_pool_t.set_parent_pool()):

      try:
        application_pool_lock.acquire()

        # XXX find out who calls us:
        import os, traceback
        traceback.print_stack(file=open('/tmp/libsvn-%d.log' % os.getpid(), 'a'))
        # XXX (see #T10421)

        self._parent_pool = parent_pool or application_pool

Look then at the beginning of that debug output file, search for svn_pool_create() and see "who" calls it.

[Christian Boos]

Not much we can do here, parking the issue…