id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
26214	Better error message for RuntimeError: populate() isn't reentrant	Thomas Güttler		"We were hit by an exception like this in production environment

{{{
Traceback (most recent call last):
  File ""/home/foobar_fm_p/src/foobar-fm/foobar_fm/apache/django_wsgi.py"", line 4, in <module>
    application = wsgi.get_handler()
  File ""/home/foobar_fm_p/src/djangotools/djangotools/utils/wsgi.py"", line 54, in get_handler
    return get_wsgi_application()
  File ""/home/foobar_fm_p/lib/python2.7/site-packages/django/core/wsgi.py"", line 14, in get_wsgi_application
    django.setup()
  File ""/home/foobar_fm_p/lib/python2.7/site-packages/django/__init__.py"", line 18, in setup
    apps.populate(settings.INSTALLED_APPS)
  File ""/home/foobar_fm_p/lib/python2.7/site-packages/django/apps/registry.py"", line 78, in populate
    raise RuntimeError(""populate() isn't reentrant"")
RuntimeError: populate() isn't reentrant
}}}

To debug this, I am missing an very important part:

The Stacktrace of the other one trying to load the config

Here is the code part
{{{

            # app_config should be pristine, otherwise the code below won't
            # guarantee that the order matches the order in INSTALLED_APPS.
            if self.app_configs:
                raise RuntimeError(""populate() isn't reentrant"")
}}}

My idea: the first one, who passes above check stores its current stracktrace to a variable.

The if the second fails, and RuntimeError(""populate() isn't reentrant"") gets executed, the exception can show the stacktrace of the first run.

With this you can debug it. Otherwise you are lost.

What do you think?"	Uncategorized	new	Error reporting	1.9	Normal				Unreviewed	0	0	0	0	0	0