RuntimeError: instance.__dict__ not accessible in restricted mode

[Max Bowsher <maxb1@…>]

In all probability, this is not a bug in Trac, but in either Subversion, SWIG, or mod_python - I am filing this ticket principally so that there is somewhere to collect reports of this problem, and make notes of any debugging that is done.

I experience an intermittent Trac internal error, with the following environment:

• Debian 'etch'
• SWIG 1.3.28-1.1
• Apache HTTPD 2.2.2
• Subversion 1.3.2 (using the above SWIG)
• mod_python 3.2.9-rc3
• Trac 0.10dev r3492

Traceback (most recent call last):
  File "/home/maxb/wc/trac/trunk/trac/web/main.py", line 314, in dispatch_request
    dispatcher.dispatch(req)
  File "/home/maxb/wc/trac/trunk/trac/web/main.py", line 199, in dispatch
    resp = chosen_handler.process_request(req)
  File "/home/maxb/wc/trac/trunk/trac/versioncontrol/web_ui/browser.py", line 95, in process_request
    repos = self.env.get_repository(req.authname)
  File "/home/maxb/wc/trac/trunk/trac/env.py", line 194, in get_repository
    return RepositoryManager(self).get_repository(authname)
  File "/home/maxb/wc/trac/trunk/trac/versioncontrol/api.py", line 70, in get_repository
    self.repository_dir, authname)
  File "/home/maxb/wc/trac/trunk/trac/versioncontrol/svn_fs.py", line 262, in get_repository
    repos = SubversionRepository(dir, authz, self.log)
  File "/home/maxb/wc/trac/trunk/trac/versioncontrol/svn_fs.py", line 279, in __init__
    self.pool = Pool()
  File "/home/maxb/wc/trac/trunk/trac/versioncontrol/svn_fs.py", line 158, 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 1050, in svn_pool_create
    return apply(_core.svn_pool_create, args)
  File "/usr/local/lib/svn-python/libsvn/core.py", line 2868, in _wrap
    obj.set_parent_pool(self)
  File "/usr/local/lib/svn-python/libsvn/core.py", line 2781, in set_parent_pool
    self._parent_pool = parent_pool or application_pool
  File "/usr/local/lib/svn-python/libsvn/core.py", line 2766, in <lambda>
    __setattr__ = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value)
  File "/usr/local/lib/svn-python/libsvn/core.py", line 22, in _swig_setattr
    return _swig_setattr_nondynamic(self,class_type,name,value,0)
  File "/usr/local/lib/svn-python/libsvn/core.py", line 17, in _swig_setattr_nondynamic
    self.__dict__[name] = value
RuntimeError: instance.__dict__ not accessible in restricted mode

Some googling suggests that this error is a hint that a Python object created in one subinterpreter is being used in a different subinterpreter. This is supported by the fact that my Trac setup does indeed involve Trac instances running under multiple subinterpreters.

Resolution

There's indeed no possibility to make it work with multiple subinterpreters per process, the workaround is to enforce the use of a single interpreter per process, as documented in TracSubversion#instance-dict-restricted-mode.

[Christopher Lenz]

Tickets #3736 and #3798 have been marked as duplicate of this ticket.

[Christian Boos]

Replying to Max Bowsher <maxb1@ukf.net>:

… Some googling suggests that this error is a hint that a Python object created in one subinterpreter is being used in a different subinterpreter. This is supported by the fact that my Trac setup does indeed involve Trac instances running under multiple subinterpreters.

Note that we anyway advise against doing this, as this is known to trigger the #2611 bug. See TracSubversion#TracandSubversion1.3.1 and #3455.

[Christian Boos]

Real issue, but unless someone tackles the problem of ditching the SVN python bindings in favor of e.g. PySvn, it's not something we can act upon immediately.

[anonymous]

In my opinion this problem is currently the most severe blocker as it arises very often for me and influences the experience of Trac usage extremely negatively. I have read through the various bug reports on this, but I'm still not sure what's the cause of it.

Could one of the Trac developers PLEASE elaborate on

• the cause of the problem
• workarounds

Thanks very much in advance.

[Christian Boos]

Replying to anonymous:

Could one of the Trac developers PLEASE elaborate on

• the cause of the problem
• workarounds

This is a limitation of mod_python and its default setup (i.e. usage of multiple subinterpreteres) in presence of complex extensions. See ​this mail, which also explains the workaround (force use of the first interpreter), and ​MODPYTHON:77.

Apparently, the fix made for mod_python-3.3 has been backported (​rev 383731) for mod_python-3.2.10, so it would be interesting to get feedback from people using that version.

[Tim Hatch]

Ticket #4457 has been marked as a duplicate.

[sami at etopian net]

I am using mod_python-3.2.10 and I still do see this problem intermittently.

[Emmanuel Blot]

Ticket #4495 has been marked as a duplicate.

[djames]

I'm marking this bug as a duplicate of #3455, because nobody has reproduced this bug using mod_python 3.2.8 or later and PythonInterpreter main_interpreter.

If someone can reproduce this bug using mod_python 3.2.8 or later and PythonInterpreter main_interpreter, feel free to reopen this bug.

[anonymous]

Marking as duplicate of #3455

[Christian Boos]

The fix was only supposed to be there in mod_python 3.2.8, btw (see comment:5).

So what about comment:7? sami, are you using the PythonInterpreter main_interpreter workaround?

[Christian Boos]

Sorry, I meant 3.2.10 in the above comment.

[Christian Boos]

#4605 was marked as duplicate.

[aymeric mansoux]

Replying to cboos:

Apparently, the fix made for mod_python-3.3 has been backported (​rev 383731) for mod_python-3.2.10, so it would be interesting to get feedback from people using that version.

here:

• debian 2.6.15-1-686
• subversion 1.2.3dfsg1-3
• trac 0.10.3-1
• apache 2.2.3-3.1
• mod_python 3.2.10-3
• python 2.4.3-11

apache config:

        <Location /puredyne>
                SetHandler mod_python
                PythonHandler trac.web.modpython_frontend
                PythonOption TracEnv /goto/trac/puredyne
                PythonOption TracUriRoot /puredyne
                SetEnv PYTHON_EGG_CACHE /goto/trac-eggs
                PythonInterpreter main_interpreter
        </Location>

and we still have the bug… any suggestion welcome, it's very hard to work with this issue.

[aymeric mansoux]

updated to pyton 2.4.4-2 and still crashes 90% of the time … please help.

[aymeric mansoux]

updated to mod_python 3.3.0b and still crashes (less though, but still crashing enough to make the whole working experience very annoying)

[Christian Boos]

Well, subversion 1.2.3dfsg1-3 that's pretty old. Can you upgrade to 1.4.3?

[aymeric mansoux]

Yup, sorry to mentionned it, I also updated Subversion (1.4.2dfsg1-2) when I was trying to upgrade some critical components.

Unfortunately as mentionned previously this did not help. Worse, since I moved to mod_python 3.3.0b the problem occurs almost permanently. At first I thought it was better but no. Strangely when I restart apache, there is a period of calm, then the issue comes back with a growing frequency until trac becomes impossible to use.

Last but not least we have 3 trac environments running ​http://packets.goto10.org , ​http://desiredata.goto10.org and ​http://puredyne.goto10.org the last one is by far the one which is suffering the most from this problem.

[Christian Boos]

Replying to aymeric mansoux:

Last but not least we have 3 trac environments running […] the last one is by far the one which is suffering the most from this problem.

Any additional information about what differentiate those environments? Bigger repository, frequency of access, etc. ? That may hint to the reason of the error.

Also, which Apache mpm are you using? worker or prefork?

A few suggestions for investigating the problem further:

• switch to the other mpm model than the one you're currently using
• use Apache 2.0.x instead of 2.2.x

(btw, I assume that there's none of the "usual" problems that can happen with Apache + Subversion, mainly that you're using the same combination of apr libs)

[Christian Boos]

[OT] interesting… the quote ellipsis in the comment above [...] was interpreted as a relative link, need to fix that.

[anonymous]

Also dealing with this problem.. multiple trac installs via mod_python on a single machine. One of them is crashing with this trace relentlessly. I can restart apache and it's good for a few minutes but it starts up again. Put that main_interpreter fix in and it doesn't seem to help.

[anonymous]

Sorry, more info:

Debian / Linux 2.6.18-3-686 SVN 1.4.2 (r22196) Trac 0.10.3 Apache/2.2.3 mod_python 3.2.10-3 swig 1.3.29-2.1

[psicot_at_gmail.com]

I have exactly the same problem on my debian sever (etch), apache2.0, trac 0.10.4dev, python24 and libapache2-mod-python3.2.10-3.

[Christian Boos]

It would be very interesting to know which Apache mpm are concerned… only worker or also prefork?

Please, the concerned reporters should follow-up on their comments (comment:18, comment:22 and comment:23) with this information.

If this problem is only affecting the worker model, then using the prefork model would be a workaround.

[anonymous]

I'm comment:22, and it looks like I've got only mpm-worker. I am not positive how to check, but my /var/lib/dpkg/info/ only has mpm-worker files.

[anonymous]

(comment:22, comment:25 is me) I just installed mpm-prefork. I will report back after I can tell if it the problem has gone.

[anonymous]

(i'm comment:26) — no problems in the last day or so with mpm-prefork.

[anonymous]

(comment:27) — nope, spoke too soon. Got the trace this a.m. It does seem less pronounced these days but I have no hard data. Any other suggestions?

[aymeric mansoux]

Replying to cboos:

Any additional information about what differentiate those environments? Bigger repository, frequency of access, etc. ? That may hint to the reason of the error.

3 repositories, the crashing one is the biggest and the most accessed, it was also the one that was created the 1st out of the 3.

Also, which Apache mpm are you using? worker or prefork?

prefork

A few suggestions for investigating the problem further:

• switch to the other mpm model than the one you're currently using

That is not possible as the machine also runs squirrelmail and moving to worker would remove libapache2-mod-php5, php5-gd, php5-mysql and squirrelmail

• use Apache 2.0.x instead of 2.2.x

I would like to avoid to downgrade blindly, unless someone can suggest THE working setup and all the right debian packages precise version numbers to use.

(btw, I assume that there's none of the "usual" problems that can happen with Apache + Subversion, mainly that you're using the same combination of apr libs)

no dirty tricks on the server, plain debian etch testing.

[vinvin]

I've just added mod_ssl to my debian unstable's apache, so I can access trac using HTTP or HTTPS. I get this intermittent error with the HTTPS, but not with the standard HTTP access. No one has talked about mod_ssl before, but I thought that might give you a clue about why it is happening. I don't understand either, this is really wierd to get such an intermittent bug :(

• Apache 2.2.3-3.3
• mod_python 3.2.10-3
• python 2.4.4-2
• trac 0.10.3-1

Multiple trac interfaces, bug happening on all.

[Christian Boos]

Thanks for the info, that seems very interesting indeed. I've not yet seen the error myself (mod_python 3.3.1, Apache 2.0.59 prefork), but I also don't use https…

Replying to vinvin:

I get this intermittent error with the HTTPS, but not with the standard HTTP access.

not as in never, or simply less frequently?

Note to the other subscribers to this ticket: please mention if you're seeing this in combination with mod_ssl as well (or if mod_ssl is enabled in your apache).

[Christian Boos]

Follow-up to 31:

… please mention if you're seeing this in combination with mod_ssl as well (or if mod_ssl is enabled in your apache).

From the many duplicates of this ticket I've just checked, the error seems to happen also with ​http:// queries. However, that might nevertheless be related to mod_ssl being used by the same httpd process, for handling other queries.

[vinvin]

Replying to cboos:

not as in never, or simply less frequently?

When I wrote it it was never, but you're actually right, it is less frequently. It may happen twice and then work fine for 20 hits so it's not easy to quantifiate. In HTTPS, it often happens on the firsts hits. Maybe it's a load average thing, with ssl on my little cpu the execution flow might be different…

But indeed, other reports were for HTTP only, and as it happens for me too now, I don't think it is mod_ssl related :( sorry

[aymeric mansoux]

We had errors with both http and https (mod_ssl)

We moved to fastcgi now, because it was impossible to work anymore, and it works like a charm.

Thanks for the support so far, good luck finding out about this issue!

a.

[Christian Boos]

Replying to aymeric mansoux:

We had errors with both http and https (mod_ssl)

If it's possible for you (or anyone else who reliably had the error) to do some experimentations, I wonder if the error would still be there if you simply disable the mod_ssl module from the apache configuration, to make sure the library doesn't even get loaded.

[vinvin]

Replying to cboos:

I wonder if the error would still be there if you simply disable the mod_ssl module from the apache configuration, to make sure the library doesn't even get loaded.

I've just disabled mod_ssl, and it works fine with HTTP !

That finally might be mod_ssl related :)

[Christian Boos]

DLL Hell once again! ;-)

[Emmanuel Blot]

#4938 has been marked as a duplicate

[anonymous]

I'm comment:28 and many before… I am getting this much much more after upgrading to 0.10.3.1. It was at 10% previously and now at 60%. All of our developers are trained to copy their wiki edits to the clipboard before submitting, but this can't last long!

We are running under ​https://. Is there anything I can try?

[Christian Boos]

Replying to anonymous:

I'm comment:28 and many before…

Hm, it's a bit hard to track your contributions, even with those wonderful in reply to links ;-), so maybe next time it will help to choose a pseudonym instead of staying anonymous?

Therefore I'm asking again: do you use the PythonInterpreter main_interpreter workaround or not? If not, you are urged to do so…

Is there anything I can try?

You can try to switch to the latest mod_python (3.3.1 I think). If you're really desperate, see comment:34.

[mrenzmann@…]

Replying to djames:

If someone can reproduce this bug using mod_python 3.2.8 or later and PythonInterpreter main_interpreter, feel free to reopen this bug.

I'm running Trac 0.10.3.1 on Apache 2.2.3 with mpm_worker, mod_python 3.2.10, Python 2.4.4 and Subversion 1.4.2 (via mod_svn) on Debian Etch. The server hosts three Trac environments, each sitting on their own VHost. mod_ssl is not available on this server, neither is mod_php.

The sites recently moved to this new server. We experienced this issue on the old server (Debian Etch, Apache 2.0.54, mpm_prefork, with mod_ssl and mod_php loaded), so I applied the PythonInterpreter main_interpreter there and it helped afair. When moving the sites to the new server I didn't remove the workaround, and I just verified that it's still enabled. Nevertheless we see this error occasionally.

mpm_worker configuration looks like this:

StartServers           2
MaxClients           150
MinSpareThreads       25
MaxSpareThreads       75
ThreadsPerChild       25
MaxRequestsPerChild 4096

From what I can tell so far it looks like this issue appears only when more than two processes are active and it seems to occur only for requests that are not served by a thread of process 1 or 2. However, the latter is just a guess and still needs to be confirmed.

This would explain why we saw the issue going away automatically on our site after some time with less traffic. And today I verified that a restart of Apache solved it, too.

In reply to cboos in comment:35:

If it's possible for you (or anyone else who reliably had the error) to do some experimentations, I wonder if the error would still be there if you simply disable the mod_ssl module from the apache configuration, to make sure the library doesn't even get loaded.

mod_ssl is not loaded on this server (but was on the old), thus the sites are not accessed via https. I'm pretty sure that the mod_ssl hint is a red herring.

[prasana.iyengar@…]

We are using

1. libapache2-mod-python 3.2.10-4
2. and PythonInterpreter main_interpreter

After the mod_python upgrade to 3.2.10 - the problem occurrence has reduced but it came back this AM. I have restarted apache2 and that seems to make the problem go away [can't tell for sure if that is the behavior].

1. I wanted to check if any others have seen the Internal Server error after apache/python have been running for a while ?
2. Is moving to lighttpd a recommended step.

thanks - I am new to running this trac environment - and saw this ticket about this problem - not sure if there is another mechanism to report these issues.

thanks for a very useful piece of software.

-prasana

[Noah Kantrowitz]

#5092 has been marked a duplicate of this ticket.

[Axel.Thimm@…]

We're experiencing this, too, over at lm-sensors.org. The server is running FC6/x86_64 and uses

httpd-2.2.3-5
mod_python-3.2.8-3.1
trac-0.10.3.1-19.fc6.at
python-2.4.4-1.fc6
subversion-1.4.2-2.fc6

[vinvin]

debian stable (the new one) has still this problem ! (which makes it not stable to me…)
I did not mentioned before I was using mpm-prefork.

I may have a new clue, on apache error logs I have messages like :
[notice] child pid 9035 exit signal Segmentation fault (11)

After a while, the ssl mod seems to be fully dead, cause I have these errors :
[error] [client 192.168.1.3] Invalid method in request \x80L\x01\x03\x01

I think it is still stable without mod_ssl enabled, but that could be nice to have it…

[anonymous]

Replying to vinvin:

I think it is still stable without mod_ssl enabled, but that could be nice to have it…

As mentioned above, I experience this issue even without having mod_ssl enabled at all, so I'm still confident that the mod_ssl hint is a red herring.

[Axel.Thimm@…]

Replying to Axel.Thimm@ATrpms.net:

We're experiencing this, too, over at lm-sensors.org. The server is running FC6/x86_64 and uses

httpd-2.2.3-5
mod_python-3.2.8-3.1
trac-0.10.3.1-19.fc6.at
python-2.4.4-1.fc6
subversion-1.4.2-2.fc6

We have used

PythonInterpreter main_interpreter

and it looks like it works now, or at least fails so infrequent that our tests did not catch it.

FWIW mod_ssl is enabled and there are several other VirtualHosts running on this setup.

[vinvin]

It finally seems it was not an ssl issue, but a VirtualHosts misconfiguration. I changed a NameVirtualHost directive and restarted apache and I had no segfault since.

[Christian Boos]

Replying to vinvin:

It finally seems it was (…) a VirtualHosts misconfiguration. I changed a NameVirtualHost directive and restarted apache and I had no segfault since.

For the record, can you write down what was the configuration which triggered the bug, and what is your new one?

[mrenzmann@…]

Replying to mrenzmann@otaku42.de:

From what I can tell so far it looks like this issue appears only when more than two processes are active and it seems to occur only for requests that are not served by a thread of process 1 or 2. However, the latter is just a guess and still needs to be confirmed.

By accident I just stumbled across what caused the error appear on my server. It's so damn obvious that I am a bit ashamed that I didn't find it at once… to make it short: of course the mentioned workaround (PythonInterpreter main_interpreter) has to be applied to all active vhosts on the server.

In my case I forgot to apply it for a vhost that runs with Trac. As soon as someone accessed Trac on that vhost, the "… not accessible in restricted mode" error occured on all other Trac-based sites. After recognizing the cause it was easy to fully reproduce the issue. The reason it didn't occur very often before is that the vhost in question rarely gets any visits.

Bottom line: the issue is now fixed for me, and I can confirm that the mentioned workaround works on my system as intended.

[vinvin]

Replying to cboos:

For the record, can you write down what was the configuration which triggered the bug, and what is your new one?

Sorry for not having been around. The NameVirtualHost *:443 directive was inside the <VirtualHost *:433> block instead of before it. The other thing is that it was not *:443 but the_hostname:433, I don't know if this is related. I guess I found that two in bad mod_ssl tutorials.
Since I changed this, I had no crash.

[anonymous]

I've had trouble with this bug for months and after adding PythonInterpreter main_interpreter to all the tracs on my hosts, it seems to have gone away!! Thank you mrenzmann!

[tola]

I have replicated this bug on Debian etch with multiple track environments, not running mod_ssl.

Currently trying the PythonInterpreter main_interpreter fix, seems to be helping but I'll give it time.

[anonymous]

I'm seeing this bug on FC6 with apache, mod_python, and I am using the "PythonInterpreter main_interpreter" fix. Versions of software I'm using:

mod_python-3.2.8-3.1 httpd-2.2.4-2.fc6 python-2.4.4-1.fc6 trac-0.10.3.1-2.fc6

[Christian Boos]

Replying to anonymous:

I'm seeing this bug on FC6 with apache, mod_python, and I am using the "PythonInterpreter main_interpreter" fix. Versions of software I'm using:

mod_python-3.2.8-3.1 httpd-2.2.4-2.fc6

You should be using the latest stable version of mod_python (3.3.1).

python-2.4.4-1.fc6

trac-0.10.3.1-2.fc6

That's also not the latest stable release (not that it does matter for this issue, but nevertheless).

[anonymous]

FC6 is using python-2.4, so unfortunately can't upgrade easily to mod_python-3.3.1; would need to upgrade to F7, but want to avoid doing that because this is a server used for other purposes as well.

Replying to cboos:

Replying to anonymous:

I'm seeing this bug on FC6 with apache, mod_python, and I am using the "PythonInterpreter main_interpreter" fix. Versions of software I'm using:

mod_python-3.2.8-3.1 httpd-2.2.4-2.fc6

You should be using the latest stable version of mod_python (3.3.1).

python-2.4.4-1.fc6

trac-0.10.3.1-2.fc6

That's also not the latest stable release (not that it does matter for this issue, but nevertheless).

[anonymous]

Just for completeness: we resolved this issue on FC6 by rebuilding mod_python-3.3.1 from rpm source (apparently doesn't need python 2.5) and upgrading mod_python to 3.3.1, and using the PythonInterpreter main_interpreter fix mentioned above.

Replying to anonymous:

FC6 is using python-2.4, so unfortunately can't upgrade easily to mod_python-3.3.1; would need to upgrade to F7, but want to avoid doing that because this is a server used for other purposes as well.

Replying to cboos:

Replying to anonymous:

I'm seeing this bug on FC6 with apache, mod_python, and I am using the "PythonInterpreter main_interpreter" fix. Versions of software I'm using:

mod_python-3.2.8-3.1 httpd-2.2.4-2.fc6

You should be using the latest stable version of mod_python (3.3.1).

python-2.4.4-1.fc6

trac-0.10.3.1-2.fc6

That's also not the latest stable release (not that it does matter for this issue, but nevertheless).

[dom@…]

Just to clarify - the PythonInterpreter main_interpreter (or anything else - I used 'PythonIntpreter "trac"') needs to appear on every trac instance on the server - by default it's named after the virtualhost, but we need to have all the tracs being run inside one interpreter. So far, this seems to have fixed the problems on my server (Debian etch with default versions of everything).

[Christian Boos]

The workaround is well documented (TracSubversion#instance-dict-restricted-mode and TracModPython#Subversionissues) and the workaround has been confirmed many times now. Closing.

Many thanks to all the people who contributed to clarify the issue.

[mrenzmann@…]

I think it's worth to point out a downside of this workaround:

I have several Trac instances (each in their own vhost) running on the same Apache/server. One of them is my playground, that I also use for testing modifications I've made to plugins. In other words: if I have a plugin that is used in one of the "production" instances and I want to test a modification to that plugin, I switch to an updated egg for the "playground" instance (while the "production" instance stays on the old version).

However, this doesn't work at all with the PythonInterpreter main_interpreter workaround being enabled.

It took me several hours to find that out. Altough the playground instance had the updated egg, the previous version was constantly unpacked and used. This behaviour did change only when I disabled the workaround, which caused the "… not accessible in restricted mode" stuff to reappear. *sigh*

[Christian Boos]

Well, having multiple Python subinterpreters for isolating a playground is not a solution, as that won't work well when C extensions come into play (like demonstrated here). That's "fact" and there's nothing Trac could do about, except suggesting workarounds. In your scenario (playground/experimental setup), I'd suggest either one of the following solutions:

1. have a complete separate Apache environment on a different port (or different server?)
2. still with Apache, drop TracModPython and use TracModWsgi in daemon mode
3. drop Apache and use the all-mighty tracd ;-)

The TracModPython setup with multiple environments is only "robust" as long as you want to have a coherent set of extensions used. Maybe the day Trac no longer requires any C based extension, using multiple sub-interpreters could be an option again.

[anonymous]

I am getting this error, too. Could we please find a solution to this?

[ilias@…]

The workaround with "PythonInterpreter main_interpreter" does not work on my Suse 10.2 / python 2.5 server. This may relates to the #6549 memory issue. will report on this shortly.

[ilias@…]

The workaround works, it's just important to configure all virtual hosts on the machine to use the main_interpreter, as described within comment:59

[sasserstyl]

I had this error on Ubuntu Gutsy/Apache 2.2.4/Trac 10.4 when added a new virtual host in apache (to enable SSL support).

Changing the server name in the virtual host from:

<ip address>:443 to <machine name>:443

(as found in the non-ssl virtual host file) appears to have fixed the issue.

Maybe accessing the same trac through two diffeently configured virtual hosts causes the issue?

[mbchambers@…]

instance.dict not accessible in restricted mode - BOINC - Trac

The above is the title of my version of this error. Since other "tickets" similar to mine have been closed as "duplicates", I thought I would post this here. Really, this is all hopelessly obscure jargon to me, from "ticket" to "Trac", but here is my foolish attempt to follow directions…

I am using the BOINC Manager 6.2.1 Pre-release (a Windows Vista 32-bit version) attempting to open the "Help" menu > "BOINC website" menu item, opening a Firefox/3.0b5 window. (This is the address of the failed webpage opening: ​http://boinc.berkeley.edu/trac/wiki/ManagerAdvanced )

It happened once, I tried it again, it happened again. I opened Internet Explorer, set it as the default, and tried it again and got the same result.

Here is a full cut and paste of the error messages:

Oops… Trac detected an internal error:

If you think this really should work and you can reproduce it, you should consider reporting this problem to the Trac team.

Go to ​http://trac.edgewall.org/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the Python traceback found below.

TracGuide — The Trac User and Administration Guide Python Traceback

Traceback (most recent call last):

File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 406, in dispatch_request

dispatcher.dispatch(req)

File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 191, in dispatch

chosen_handler = self._pre_process_request(req, chosen_handler)

File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 263, in _pre_process_request

chosen_handler = f.pre_process_request(req, chosen_handler)

File "/usr/lib/python2.5/site-packages/trac/versioncontrol/api.py", line 73, in pre_process_request

self.get_repository(req.authname).sync()

File "/usr/lib/python2.5/site-packages/trac/versioncontrol/api.py", line 104, in get_repository

repos = self._connector.get_repository(rtype, rdir, authname)

File "/usr/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 234, in get_repository

repos = SubversionRepository(dir, None, self.log)

File "/usr/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 256, in init

self.pool = Pool()

File "/usr/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 133, in init

self._pool = core.svn_pool_create(self._parent_pool())

File "/usr/lib/python2.5/site-packages/svn/core.py", line 177, in svn_pool_create

return Pool(parent_pool)

File "/usr/lib/python2.5/site-packages/libsvn/core.py", line 1082, in svn_pool_create

return apply(_core.svn_pool_create, args)

File "/usr/lib/python2.5/site-packages/libsvn/core.py", line 3083, in _wrap

obj.set_parent_pool(self)

File "/usr/lib/python2.5/site-packages/libsvn/core.py", line 2996, in set_parent_pool

self._parent_pool = parent_pool or application_pool

File "/usr/lib/python2.5/site-packages/libsvn/core.py", line 2984, in <lambda>

setattr = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value)

File "/usr/lib/python2.5/site-packages/libsvn/core.py", line 24, in _swig_setattr

return _swig_setattr_nondynamic(self,class_type,name,value,0)

File "/usr/lib/python2.5/site-packages/libsvn/core.py", line 19, in _swig_setattr_nondynamic

self.dict[name] = value

RuntimeError: instance.dict not accessible in restricted mode

[ilias@…]

BOINC!

you should simply follow the mentioned workaround ( see comment:64). If you're not familar with 'trac' and 'ticket', you should contact an admin on your site.

[EoghanM]

Replying to sasserstyl:

Maybe accessing the same trac through two diffeently configured virtual hosts causes the issue?

I had a similar solution - I have 3 virtual hosts with 3 tracs. Only one of them was giving me the error. I moved the Auth configuration outside of the <Location> section, as follows, and this seems to have fixed it. The commented out lines below was the only difference I could find between the configuration of the 3 virtual hosts:

    <Location />
        SetHandler mod_python
        PythonHandler trac.web.modpython_frontend
        PythonOption TracEnv /trac/project1
        PythonOption TracUriRoot /
        PythonDebug on
        SetEnv PYTHON_EGG_CACHE /home/me/.python-eggs-old

#        AuthType Basic
#        AuthName "Trac"
#        AuthUserFile /home/me/svn.passwd
#        Require user me
    </Location>

[EoghanM]

Replying to EoghanM:

As a follow up: 2 weeks later and I've suddenly started getting this error again.

[EoghanM]

Replying to EoghanM:

As mentioned earlier in the thread (I missed it), this is solved: ​http://trac.edgewall.org/wiki/TracSubversion#instance-dict-restricted-mode

[denis]

Well, I have "PythonInterpreter main_interpreter" in <Location> but I still get the error occassionally.

[bartosz.broda@…]

Unfortunately this problem is still not resolved on Debian Lenny (using all packages from repository). I have 8 instances of Trac running using apache2 and mod_wsgi with WSGIApplicationGroup %{GLOBAL}. Approximately 1 on 5 page reloads are generating

RuntimeError: instance.__dict__ not accessible in restricted mode

Trace:

Most recent call last: 
File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 423, in _dispatch_request
  dispatcher.dispatch(req)
File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 173, in dispatch
  chosen_handler)
File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 286, in _pre_process_request
  chosen_handler = filter_.pre_process_request(req, chosen_handler)
File "/usr/lib/python2.5/site-packages/trac/versioncontrol/api.py", line 86, in pre_process_request
  self.get_repository(req.authname).sync()
File "/usr/lib/python2.5/site-packages/trac/versioncontrol/api.py", line 157, in get_repository
  repos = self._connector.get_repository(rtype, rdir, authname)
File "/usr/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 280, in get_repository
  'branches': self.branches})
File "/usr/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 390, in __init__
  self.pool = Pool()
File "/usr/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 151, in __init__
  self._pool = core.svn_pool_create(self._parent_pool())
File "/var/lib/python-support/python2.5/svn/core.py", line 248, in svn_pool_create
  return Pool(parent_pool)
File "/var/lib/python-support/python2.5/libsvn/core.py", line 1440, in svn_pool_create
  return apply(_core.svn_pool_create, args)
File "/var/lib/python-support/python2.5/libsvn/core.py", line 5010, in _wrap
  obj.set_parent_pool(self)
File "/var/lib/python-support/python2.5/libsvn/core.py", line 4923, in set_parent_pool
  self._parent_pool = parent_pool or application_pool
File "/var/lib/python-support/python2.5/libsvn/core.py", line 4911, in <lambda>
  __setattr__ = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value)
File "/var/lib/python-support/python2.5/libsvn/core.py", line 24, in _swig_setattr
  return _swig_setattr_nondynamic(self,class_type,name,value,0)
File "/var/lib/python-support/python2.5/libsvn/core.py", line 19, in _swig_setattr_nondynamic
  self.__dict__[name] = value

I'm using trac 0.11.1, python 2.5.2, Subversion 1.5.1 (r32289).

This bug happens not only when accessing code browser, but in strange different places, e.g., when trying to set user preferences.

[Christian Boos]

Replying to bartosz.broda@…:

Unfortunately this problem is still not resolved on Debian Lenny (using all packages from repository). I have 8 instances of Trac running using apache2 and mod_wsgi with WSGIApplicationGroup %{GLOBAL}. Approximately 1 on 5 page reloads are generating …

And which mod_wsgi version? Would you mind testing with a new version of mod_wsgi or have a try with mod_python (3.3.1)?

I think the version of Trac or Subversion is irrelevant for this issue, so no need to upgrade those if you don't want to.

This bug happens not only when accessing code browser, but in strange different places, e.g., when trying to set user preferences.

That's to be expected, as 0.11.x attemps a resync at the start of every request.

[bartosz.broda@…]

Thanks for quick reply!

Replying to cboos:

Replying to bartosz.broda@…:

Unfortunately this problem is still not resolved on Debian Lenny (using all packages from repository). I have 8 instances of Trac running using apache2 and mod_wsgi with WSGIApplicationGroup %{GLOBAL}. Approximately 1 on 5 page reloads are generating …

And which mod_wsgi version? Would you mind testing with a new version of mod_wsgi or have a try with mod_python (3.3.1)?

I am using mod_wsgi 2.5 (exactly: 2.5-1~lenny1). I'll try with mod_python and report if the bug still occurs.

I think the version of Trac or Subversion is irrelevant for this issue, so no need to upgrade those if you don't want to.

That's good to hear.

This bug happens not only when accessing code browser, but in strange different places, e.g., when trying to set user preferences.

That's to be expected, as 0.11.x attemps a resync at the start of every request.

Should I try to upgrade to newer version? I'd rather not (I am working in semi-production environment) unless all the other things fail…

I'll report back in a few minutes with results of running track through mod_python…

[anonymous]

Replying to bartosz.broda@… and cboos:

And which mod_wsgi version? Would you mind testing with a new version of mod_wsgi or have a try with mod_python (3.3.1)?

I am using mod_wsgi 2.5 (exactly: 2.5-1~lenny1). I'll try with mod_python and report if the bug still occurs.

It seems to be working flawlessly with mod_python (with PythonInterpreter main_interpreter). Obviously, my setup needs more testing, but with mod_wsgi the error would occur a few times till now…

It is strange as i thought that mod_wsgi was now preferred way to host python application in apache. What is more surprising is that with mod_wsgi Trac is faster (and the difference is huge!).

Thanks cboos for your suggestion!

[Christian Boos]

I think you said "worksforme" a bit hastily. You should really try to get this to work with mod_wsgi as this is indeed the preferred way.

Maybe your WSGIApplicationGroup %{GLOBAL} directive is not correctly applied. Be sure to respect all the instructions given in ​IntegrationWithTrac.

I think we could actually put more "system info" about the actual configuration in the /about page, that would help troubleshoot such issues.

[bartosz.broda@…]

Ok. I'll investigate it more (but I'll have to setup another vm-based environment for testing, as people had started using the Trac already so it will take some time). During the setup I read quickly ​mod_wsgi guide. I'll read it again and follow those instruction and report back.

More info on my previous mod_wsgi setup:

For installation using mod_wsgi I followed the ​TracModWSGI guide. For creation of wsgi scripts I used the trac-admin <env> deploy <dir>. It worked fine for one project. After moving to two separate Trac projects it was still ok. Only after I added another 6 more environments the RuntimeError was occurring constantly…

[hongbin niu]

I am very sorry to say I also met this problem.below is information for this:
Indeed,it is a sporadic problem.Would you please tell me how to resovle it
thoroughly?
…
User Agent was: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

System Information

Trac	0.11.5
Python	2.4.3 (#1, Dec 11 2006, 11:39:03) [GCC 4.1.1 20061130 (Red Hat 4.1.1-43)]
setuptools	0.6c8
SQLite	3.3.6
pysqlite	1.1.7
Genshi	0.5
mod_python	3.2.8
jQuery:	1.2.6

Python Traceback

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 444, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 175, in dispatch
    chosen_handler)
  File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 295, in _pre_process_request
    chosen_handler = filter_.pre_process_request(req, chosen_handler)
  File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/api.py", line 86, in pre_process_request
    self.get_repository(req.authname).sync()
  File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/api.py", line 130, in get_repository
    candidates = [
  File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/core.py", line 70, in extensions
    return filter(None, [component.compmgr[cls] for cls in extensions])
  File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/core.py", line 207, in __getitem__
    component = cls(self)
  File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/core.py", line 111, in maybe_init
    init(self)
  File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/svn_fs.py", line 262, in __init__
    Pool()
  File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/svn_fs.py", line 155, in __init__
    self._pool = core.svn_pool_create(self._parent_pool())
  File "/usr/lib64/python2.4/site-packages/svn/core.py", line 177, in svn_pool_create
    return Pool(parent_pool)
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 1080, in svn_pool_create
    return apply(_core.svn_pool_create, args)
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 3081, in _wrap
    obj.set_parent_pool(self)
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2994, in set_parent_pool
    self._parent_pool = parent_pool or application_pool
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2982, in <lambda>
    __setattr__ = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value)
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 22, in _swig_setattr
    return _swig_setattr_nondynamic(self,class_type,name,value,0)
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 17, in _swig_setattr_nondynamic
    self.__dict__[name] = value
RuntimeError: instance.__dict__ not accessible in restricted mode

a new ticket at the Trac project site, where you can describe the problem and explain how to reproduce it.

Python Traceback
Most recent call last: 
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 444, in _dispatch_request 
Code fragment:
    try:        if not env and env_error:            raise HTTPInternalError(env_error)        try:            dispatcher = RequestDispatcher(env)
                                      dispatcher.dispatch(req)
                                  except RequestDone:            pass        resp = req._response or []     except HTTPException, e:
                        Local variables:
Name Value 
after [u'        except RequestDone:', u'            pass', u'        resp = ... 
before [u'    try:', u'        if not env and env_error:', u'            raise ... 
dispatcher <trac.web.main.RequestDispatcher object at 0x5555692c93d0> 
e <exceptions.RuntimeError instance at 0x555569fe1cf8> 
env <trac.env.Environment object at 0x2aaabeff2dd0> 
env_error None 
exc_info (<class exceptions.RuntimeError at 0x2aaaaab09530>, ... 
filename '/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py' 
frames [{'function': '_dispatch_request', 'lines_before': [u'    try:', u'        ... 
has_admin True 
line u'            dispatcher.dispatch(req)' 
lineno 443 
message u'RuntimeError: instance.__dict__ not accessible in restricted mode' 
req <Request "GET u'/'"> 
resp [] 
tb <traceback object at 0x555569cb8950> 
tb_hide None 
traceback u'Traceback (most recent call last):\n  File ... 

File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 175, in dispatch 
Code fragment:
                        if not req.path_info or req.path_info == '/':                            chosen_handler = self.default_handler                    # pre-process any incoming request, whether a handler                    # was found or not                    chosen_handler = self._pre_process_request(req,
                                                                                         chosen_handler)
                                          except TracError, e:                    raise HTTPInternalError(e)                if not chosen_handler:                    if req.path_info.endswith('/'):                        # Strip trailing / and redirect
                        Local variables:
Name Value 
chosen_handler <trac.wiki.web_ui.WikiModule object at 0x2aaac0ead890> 
chrome <trac.web.chrome.Chrome object at 0x2aaabf0a23d0> 
e <exceptions.TypeError instance at 0x555569fe1a28> 
err (<class exceptions.RuntimeError at 0x2aaaaab09530>, ... 
handler <trac.ticket.report.ReportModule object at 0x2aaac0eada50> 
req <Request "GET u'/'"> 
self <trac.web.main.RequestDispatcher object at 0x5555692c93d0> 

File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 295, in _pre_process_request 
Code fragment:
                req.outcookie['trac_form_token']['secure'] = True            return req.outcookie['trac_form_token'].value     def _pre_process_request(self, req, chosen_handler):        for filter_ in self.filters:
                                      chosen_handler = filter_.pre_process_request(req, chosen_handler)
                                  return chosen_handler     def _post_process_request(self, req, *args):        nbargs = len(args)        resp = args
                        Local variables:
Name Value 
chosen_handler <trac.wiki.web_ui.WikiModule object at 0x2aaac0ead890> 
filter_ <trac.versioncontrol.api.RepositoryManager object at 0x2aaac0ead9d0> 
req <Request "GET u'/'"> 
self <trac.web.main.RequestDispatcher object at 0x5555692c93d0> 

File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/api.py", line 86, in pre_process_request 
Code fragment:
     def pre_process_request(self, req, handler):        from trac.web.chrome import Chrome, add_warning        if handler is not Chrome(self.env):            try:
                                          self.get_repository(req.authname).sync()
                                      except TracError, e:                add_warning(req, _("Can't synchronize with the repository "                              "(%(error)s). Look in the Trac log for more "                              "information.", error=to_unicode(e.message)))                          
                        Local variables:
Name Value 
Chrome <class 'trac.web.chrome.Chrome'> 
add_warning <function add_warning at 0x2aaabedb6de8> 
handler <trac.wiki.web_ui.WikiModule object at 0x2aaac0ead890> 
req <Request "GET u'/'"> 
self <trac.versioncontrol.api.RepositoryManager object at 0x2aaac0ead9d0> 

File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/api.py", line 130, in get_repository 
Code fragment:
    def get_repository(self, authname):        db = self.env.get_db_cnx() # prevent possible deadlock, see #4465        try:            self._lock.acquire()            if not self._connector:
                                          candidates = [
                                              (prio, connector)                    for connector in self.connectors                    for repos_type, prio in connector.get_supported_types()                    if repos_type == self.repository_type                ]
                        Local variables:
Name Value 
_[1] [] 
authname 'niuhb' 
db <trac.db.pool.PooledConnection object at 0x555569fce960> 
self <trac.versioncontrol.api.RepositoryManager object at 0x2aaac0ead9d0> 

File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/core.py", line 70, in extensions 
Code fragment:
    def extensions(self, component):        """Return a list of components that declare to implement the extension        point interface.        """        extensions = ComponentMeta._registry.get(self.interface, [])
                                  return filter(None, [component.compmgr[cls] for cls in extensions])
                               def __repr__(self):        """Return a textual representation of the extension point."""        return '<ExtensionPoint %s>' % self.interface.__name__ 
                        Local variables:
Name Value 
_[1] [] 
cls <class 'trac.versioncontrol.svn_fs.SubversionConnector'> 
component <trac.versioncontrol.api.RepositoryManager object at 0x2aaac0ead9d0> 
extensions [<class 'trac.versioncontrol.svn_fs.SubversionConnector'>] 
self <ExtensionPoint IRepositoryConnector> 

File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/core.py", line 207, in __getitem__ 
Code fragment:
        component = self.components.get(cls)        if not component:            if cls not in ComponentMeta._components:                raise TracError('Component "%s" not registered' % cls.__name__)            try:
                                          component = cls(self)
                                      except TypeError, e:                raise TracError('Unable to instantiate component %r (%s)' %                                (cls, e))        return component 
                        Local variables:
Name Value 
cls <class 'trac.versioncontrol.svn_fs.SubversionConnector'> 
component None 
self <trac.env.Environment object at 0x2aaabeff2dd0> 

File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/core.py", line 111, in maybe_init 
Code fragment:
            def maybe_init(self, compmgr, init=init, cls=new_class):                if cls not in compmgr.components:                    compmgr.components[cls] = self                    if init:                        try:
                                                      init(self)
                                                  except:                            del compmgr.components[cls]                            raise            maybe_init._original = init            new_class.__init__ = maybe_init
                        Local variables:
Name Value 
cls <class 'trac.versioncontrol.svn_fs.SubversionConnector'> 
compmgr <trac.env.Environment object at 0x2aaabeff2dd0> 
init <function __init__ at 0x2aaabef25848> 
self <trac.versioncontrol.svn_fs.SubversionConnector object at 0x555569f13690> 

File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/svn_fs.py", line 262, in __init__ 
Code fragment:
            self.log.debug('Subversion bindings imported')        except ImportError, e:            self.error = e            self.log.info('Failed to load Subversion bindings', exc_info=True)        else:
                                      Pool()
                               def get_supported_types(self):        prio = 1        if self.error:            prio = -1
                        Local variables:
Name Value 
self <trac.versioncontrol.svn_fs.SubversionConnector object at 0x555569f13690> 

File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/svn_fs.py", line 155, in __init__ 
Code fragment:
        global application_pool        self._parent_pool = parent_pool or application_pool         # Create pool        if self._parent_pool:
                                      self._pool = core.svn_pool_create(self._parent_pool())
                                  else:            # If we are an application-level pool,            # then initialize APR and set this pool            # to be the application-level pool            core.apr_initialize()
                        Local variables:
Name Value 
parent_pool None 
self <trac.versioncontrol.svn_fs.Pool object at 0x555569f13f10> 

File "/usr/lib64/python2.4/site-packages/svn/core.py", line 177, in svn_pool_create 
Code fragment:
 def svn_pool_create(parent_pool=None):  """Deprecated. Use Pool() instead. This is a compatibility  wrapper providing the interface of the Subversion 1.2.x and  earlier bindings."""
                            return Pool(parent_pool)
                           def svn_pool_destroy(pool):  """Deprecated. Pools are now destroyed automatically. If you  want to manually destroy a pool, use Pool.destroy. This is  a compatibility wrapper providing the interface of the
                        Local variables:
Name Value 
parent_pool <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 

File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 1080, in svn_pool_create 
Code fragment:
  return apply(_core.svn_swig_py_exception_type, args)SVN_ALLOCATOR_RECOMMENDED_MAX_FREE = _core.SVN_ALLOCATOR_RECOMMENDED_MAX_FREE def svn_pool_create(*args):  """svn_pool_create(apr_pool_t parent_pool, apr_allocator_t allocator) -> apr_pool_t"""
                            return apply(_core.svn_pool_create, args)
                          SVN_VER_MAJOR = _core.SVN_VER_MAJORSVN_VER_MINOR = _core.SVN_VER_MINORSVN_VER_PATCH = _core.SVN_VER_PATCHSVN_VER_MICRO = _core.SVN_VER_MICROSVN_VER_LIBRARY = _core.SVN_VER_LIBRARY
                        Local variables:
Name Value 
args (<libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 

File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 3081, in _wrap 
Code fragment:
     def _wrap(self, obj):      """Mark a SWIG object as owned by this pool"""      self.assert_valid()      if hasattr(obj, "set_parent_pool"):
                                  obj.set_parent_pool(self)
                                  return obj       elif obj is None:        return None      else:        return GenericSWIGWrapper(obj, self)
                        Local variables:
Name Value 
obj <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 
self <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 

File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2994, in set_parent_pool 
Code fragment:
      global application_pool       try:        application_pool_lock.acquire() 
                                  self._parent_pool = parent_pool or application_pool
                                  self._mark_valid()         # Protect important functions from GC        self._apr_pool_destroy = _core.apr_pool_destroy        self._svn_swig_py_clear_application_pool = \
                        Local variables:
Name Value 
parent_pool <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 
self <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 

File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2982, in <lambda> 
Code fragment:
  class apr_pool_t:    """Proxy of C apr_pool_t struct"""    __swig_setmethods__ = {}
                              __setattr__ = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value)
                              __swig_getmethods__ = {}    __getattr__ = lambda self, name: _swig_getattr(self, apr_pool_t, name)    def __init__(self): raise AttributeError, "No constructor defined"    __repr__ = _swig_repr    def set_parent_pool(self, parent_pool=None):
                        Local variables:
Name Value 
name '_parent_pool' 
self <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 
value <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 

File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 22, in _swig_setattr 
Code fragment:
        self.__dict__[name] = value    else:        raise AttributeError("You cannot add attributes to %s" % self) def _swig_setattr(self,class_type,name,value):
                              return _swig_setattr_nondynamic(self,class_type,name,value,0)
                           def _swig_getattr(self,class_type,name):    if (name == "thisown"): return self.this.own()    method = class_type.__swig_getmethods__.get(name,None)    if method: return method(self)
                        Local variables:
Name Value 
class_type <class libsvn.core.apr_pool_t at 0x5555698fcdd0> 
name '_parent_pool' 
self <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 
value <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 

File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 17, in _swig_setattr_nondynamic 
Code fragment:
            self.__dict__[name] = value            return    method = class_type.__swig_setmethods__.get(name,None)    if method: return method(self,value)    if (not static) or hasattr(self,name):
                                  self.__dict__[name] = value
                              else:        raise AttributeError("You cannot add attributes to %s" % self) def _swig_setattr(self,class_type,name,value):    return _swig_setattr_nondynamic(self,class_type,name,value,0)
                        Local variables:
Name Value 
class_type <class libsvn.core.apr_pool_t at 0x5555698fcdd0> 
method None 
name '_parent_pool' 
self <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 
static 0 
value <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ... 

File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 444, in _dispatch_request
  dispatcher.dispatch(req)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 175, in dispatch
  chosen_handler)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 295, in _pre_process_request
  chosen_handler = filter_.pre_process_request(req, chosen_handler)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/api.py", line 86, in pre_process_request
  self.get_repository(req.authname).sync()
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/api.py", line 130, in get_repository
  candidates = [
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/core.py", line 70, in extensions
  return filter(None, [component.compmgr[cls] for cls in extensions])
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/core.py", line 207, in __getitem__
  component = cls(self)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/core.py", line 111, in maybe_init
  init(self)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/svn_fs.py", line 262, in __init__
  Pool()
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/versioncontrol/svn_fs.py", line 155, in __init__
  self._pool = core.svn_pool_create(self._parent_pool())
File "/usr/lib64/python2.4/site-packages/svn/core.py", line 177, in svn_pool_create
  return Pool(parent_pool)
File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 1080, in svn_pool_create
  return apply(_core.svn_pool_create, args)
File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 3081, in _wrap
  obj.set_parent_pool(self)
File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2994, in set_parent_pool
  self._parent_pool = parent_pool or application_pool
File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2982, in <lambda>
  __setattr__ = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value)
File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 22, in _swig_setattr
  return _swig_setattr_nondynamic(self,class_type,name,value,0)
File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 17, in _swig_setattr_nondynamic
  self.__dict__[name] = value


System Information:
User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Trac: 0.11.5 
Python: 2.4.3 (#1, Dec 11 2006, 11:39:03) [GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] 
setuptools: 0.6c8 
SQLite: 3.3.6 
pysqlite: 1.1.7 
Genshi: 0.5 
mod_python: 3.2.8 
jQuery: 1.2.6 

TracGuide — The Trac User and Administration Guide 


--------------------------------------------------------------------------------
 Powered by Trac 0.11.5
By Edgewall Software. 
Visit the Trac open source project at
http://trac.edgewall.org/

[anonymous]

I just wanted to share with everyone that the

PythonInterpreter main_interpreter

…fix works for me after this popped up. After going through my logs and investigating more, I found that this was needed after installing viewvc. When using YAST to install viewvc on OpenSuse 11.1 it added a viewvc.conf apache config file which did not include this line. I added the aforementioned fix before the PythonHandler line and now things work great again.

Thanks for having such a well documented fix here.

[shatil reverse_ta teamtil.com]

Hi all, I received the same error just now and it was viewable on the local system only. Over the local network or over the net, the error didn't show.

My narrative: I accidentally chmod +x -R'd the entire directory that my particular repository was in (thanks to ​an old how-to) and I was going around trying to manually undo it.

In the end, due to the various errors I kept getting, I gave up and just chmod +x -R'd the entire directory again and after restarting apache, everything's in order again. I've removed the repo/format and repo/README.TXT files' executable permissions and it seems to be working okay still.

I'm on Debian Lenny 5.0.3 using Python 2.5.2 with Trac 0.11.1 and Subversion 1.5.1 r32289 running on PostgreSQL 8.3 (i.e., everything was installed straight from the Lenny repositories). And it looks like I forgot to grab the rest of error stack. Oh well.

[Remy Blank]

#9628 was closed as a duplicate.

Shouldn't this be closed as an InstallationIssue? I have had installations with both mod_python and mod_wsgi and have never encountered this issue.

[Christian Boos]

Well, I tend to agree, this will presumably never be solved at the Subversion bindings level, so let's just acknowledge this.

cantfix this third-party issue, the only workaround is to adhere strictly to the Installation instructions, which are to force the use of a single Python interpreter. As mentioned numerous time in this ticket, this is documented in details in TracSubversion#instance-dict-restricted-mode.

[saberin]

This was resolved for me by restarting Apache2 and trac-admin resync

[Christian Boos]

(clearing report:35)

[tony]

Replying to EoghanM:

Replying to EoghanM:

As mentioned earlier in the thread (I missed it), this is solved: ​http://trac.edgewall.org/wiki/TracSubversion#instance-dict-restricted-mode

It's still not solved.

I have tried all the suggestions in the URL given above, and yet we still get the RuntimeError: instance.__dict__ not accessible in restricted mode error (along with a bunch of other errors the same as documented elsewhere on this page).

Our environment is:

O/S: CentOS release 6.4 (Final)

Kernel:  Linux **** 2.6.32-358.6.1.el6.i686 #1 SMP Tue Apr 23 18:13:20 UTC 2013 i686 i686 i386 GNU/Linux

httpd -v
Server version: Apache/2.2.15 (Unix)
Server built:   Feb 22 2013 11:17:44

python -V
Python 2.6.6

rpm -qa|grep -i postgres
postgresql91-server-9.1.9-1PGDG.rhel6.i686
postgresql-libs-8.4.13-1.el6_3.i686
postgresql-8.4.13-1.el6_3.i686
postgresql91-libs-9.1.9-1PGDG.rhel6.i686
postgresql91-9.1.9-1PGDG.rhel6.i686

Is this ever going to be fixed?

I note that this thread appears to be about 7 years old…

[Ryan J Ollos]

Replying to tony:

Is this ever going to be fixed?

Most likely you have an InstallationIssue, so please ask on the MailingList. When you raise the issue on the mailing list, please make sure to mention what version of Trac you are running, your version of Subversion and python-subversion bindings and whether you are using mod_python (which is deprecated) or mod_wsgi. As the solution is already documented at TracSubversion#instance-dict-restricted-mode, please also make sure to show your Apache configuration.

[thomas.moschny@…]

We recently had the same issue on CentOS 6.4 with these packages:

httpd-2.2.15-29.el6.centos.x86_64
mod_wsgi-3.2-3.el6.x86_64

Setting WSGIApplicationGroup %{GLOBAL} did not help, but using a WSGIDaemonProcess actually fixed it:

Alias /trac/chrome /srv/trac/env/share/trac/htdocs
WSGIScriptAlias /trac /srv/trac/env/share/trac/cgi-bin/trac.wsgi

WSGIDaemonProcess trac
WSGISocketPrefix run/wsgi

<Directory /srv/trac/env/share/trac/cgi-bin/trac.wsgi>
  WSGIApplicationGroup %{GLOBAL}
  WSGIProcessGroup trac
  Order deny,allow
  Allow from all
</Directory>

Interestingly, that even works when passing processes=N with N>1 to WSGIDaemonProcess.