Trac should call mimetypes.init() as it is not thread-safe to not do so before python 2.6.3

[Leonardo Santagada <santagada@…>]

The mimetypes library needs that mimetypes.init() be called before threads try to use guess_type and other functions, because not doing so makes the function being called to try to call init in a non thread safe way. This has been fixed in python 2.6.3 (which was still not relased) but not before.

I want this fixed because this triggers a bug on python 2.6 on mac osx that makes it core dump.

I fixed my own copy of trac adding "import mimetypes; mimetypes.init()" on web/wsgi.py but I don't know if there is the best place to do so.

[Carsten Klein <carsten.klein@…>]

please provide you patch for a start

[Steven R. Loomis <srl@…>]

I hit this also. The python bug is ​http://bugs.python.org/issue6763 and the stack looks like:

2010-05-20 11:06:08,930 Trac[main] ERROR: Internal Server Error: 
Traceback (most recent call last):
  File "/home/srl/src/trac/trac/web/main.py", line 512, in _dispatch_request
    dispatcher.dispatch(req)
  File "/home/srl/src/trac/trac/web/main.py", line 233, in dispatch
    resp = chosen_handler.process_request(req)
  File "/home/srl/src/trac/trac/web/chrome.py", line 463, in process_request
    req.send_file(path, get_mimetype(path))
  File "/home/srl/src/trac/trac/web/api.py", line 486, in send_file
    mimetype = mimetypes.guess_type(path)[0] or \
  File "/usr/lib64/python2.6/mimetypes.py", line 242, in guess_type
    return guess_type(url, strict)
  File "/usr/lib64/python2.6/mimetypes.py", line 242, in guess_type
    return guess_type(url, strict)

[Steven R. Loomis <srl@…>]

8629mimetypes.patch

[Christian Boos]

Interesting. Note that this got me thinking about #8443 again, as all the TimeoutError we still have regularly here on t.e.o are usually happening right after application startup. I wonder if an Internal Error like this one (or other internal errors at startup) can explain why the db connections are not returned to the pool. OTOH, I've never seen anything like what you report in comment:3 in the logs.

Anyway, we should fix this, thanks for the patch!

First I had some trouble finding confirmation that code executed in an imported module is indeed executed in a thread-safe way, but at last I found ​http://docs.python.org/library/imp.html#imp.lock_held; so the patch calls mimetypes.init() the correct way.

But I don't think trac/web/__init__.py is the correct place for this, as only some scripts are using from trac.web import ..., see TracModWSGI, TracFastCgi, source:trunk/trac/web/standalone.py​, source:trunk/trac/web/mod_python.py and source:trunk/trac/admin/templates/deploy_trac.wsgi, all are directly using from trac.web.main import dispatch_request, so we should do this init() there instead. Would you mind updating the patch?

[Christian Boos]

Fix race condition during mimetypes initialization.

[Christian Boos]

… Would you mind updating the patch?

Nevermind… would you mind testing t8629-mimetypes.patch​? ;-)

[Remy Blank]

Replying to cboos:

all are directly using from trac.web.main import dispatch_request, so we should do this init() there instead.

That doesn't really matter: if you import trac.web.main, then trac.web is imported first.

[Christian Boos]

Replying to rblank:

Replying to cboos:

all are directly using from trac.web.main import dispatch_request, so we should do this init() there instead.

That doesn't really matter: if you import trac.web.main, then trac.web is imported first.

Ah, I didn't know that. OK, so it's probably safer to keep it in trac/web/__init__.py.

[Christian Boos]

Slightly modified patch applied in [9740]. Thanks!

[Steven R. Loomis <srl@…>]

welcome!