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.

[cmlenz]

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

[cboos]

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.

[cboos]

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.

[cboos]

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.

[thatch]

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.

[eblot]

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

[cboos]

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?

[cboos]

Sorry, I meant 3.2.10 in the above comment.

[cboos]

#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)

[cboos]

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.

[cboos]

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)

[cboos]

[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.

[cboos]

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.

[cboos]

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).

[cboos]

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.

[cboos]

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 :)

[cboos]

DLL Hell once again! ;-)

[eblot]

#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?

[cboos]

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

[nkantrowitz]

#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.

[cboos]

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

[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]

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).

[cboos]

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*

[cboos]

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.