Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#12843 closed (worksforme)

add user in admin causes template exception: maximum recursion depth exceeded

Reported by: mark@… Owned by: nobody
Component: contrib.admin Version: 1.1
Severity: Keywords: auth admin recursion
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Running Django 1.1.1, set up basic model structure and activated admin site. Turned on auth as described in tutorial, using 1.1.1 instructions. My models work fine in the admin interface, but I get an error when adding a user.

From Home > Auth I choose to add a user, fill in the username and password, hit Save, and:

Template error

In template /usr/lib64/python2.6/site-packages/django/contrib/admin/templates/admin/includes/fieldset.html, error at line 12
Caught an exception while rendering: maximum recursion depth exceeded
2 	{% if %}<h2>{{ }}</h2>{% endif %}
3 	{% if fieldset.description %}<div class="description">{{ fieldset.description|safe }}</div>{% endif %}
4 	{% for line in fieldset %}
5 	<div class="form-row{% if line.errors %} errors{% endif %} {% for field in line %}{{ }} {% endfor %} ">
6 	{{ line.errors }}
7 	{% for field in line %}
8 	<div{% if not line.fields|length_is:"1" %} class="field-box"{% endif %}>
9 	{% if field.is_checkbox %}
10 	{{ field.field }}{{ field.label_tag }}
11 	{% else %}
12 	{{ field.label_tag }}{{ '''field.field''' }}
13 	{% endif %}
14 	{% if field.field.field.help_text %}<p class="help">{{ field.field.field.help_text|safe }}</p>{% endif %}
15 	</div>

Change History (5)

comment:1 Changed 9 years ago by mark@…

At this stage, the user is created, but the admin site does not allow me to edit the user object further. I can successfully edit and use the user object via the shell.

comment:2 Changed 9 years ago by mark@…

Installed latest svn code (12407), problem goes away.

comment:3 Changed 9 years ago by Karen Tracey

Resolution: worksforme
Status: newclosed

I can't recreate with 1.1.1 and a machine running Python 2.6. It would be nice to know if you can recreate the problem with the latest 1.1.X branch level (I assume by latest you mean latest trunk), so we'd know whether 1.1.2, when released, might be subject to the same problem. If so we could investigate more, but we'll need more debug info. A hint of where the recursion is happening in Python code would help -- is there really no Python traceback at all in the debug information?

comment:4 Changed 9 years ago by mark@…

It was 1.1.1 from the distribution tarball (Django version 1.1.1 SVN-12407). There was a full traceback, I just didn't paste all of it.

Here's the debug output:

... and the error from the server:

[11/Feb/2010 14:53:23] "GET /admin/auth/user/ HTTP/1.1" 200 4963
Traceback (most recent call last):
  File "/usr/lib64/python2.6/site-packages/django/core/servers/", line 280, in run
  File "/usr/lib64/python2.6/site-packages/django/core/servers/", line 320, in finish_response
  File "/usr/lib64/python2.6/site-packages/django/core/servers/", line 416, in write
  File "/usr/lib64/python2.6/", line 300, in write
  File "/usr/lib64/python2.6/", line 286, in flush
error: [Errno 32] Broken pipe

Maybe something screwy in my settings, but I was pretty much following the instructions, and the current 1.2 works for me.

comment:5 in reply to:  4 Changed 9 years ago by Karen Tracey

Replying to

It was 1.1.1 from the distribution tarball (Django version 1.1.1 SVN-12407).

I'm confused. 1.1.1 from the distribution tarball would report itself as simply 1.1.1, not 1.1.1 SVN-something. Having the SVN there in the reported level implies you are running from an SVN checkout. Further the [12407] level is less than a day old, so it appears to be a fairly new checkout. However the 1.1.X branch reports itself as, for example, 1.1.2 pre-alpha SVN-12416, not 1.1.1 SVN-something. Based on that reported version, it sounds like you are running from an SVN checkout of

If you could switch to an SVN checkout of the 1.1.X branch ( then see if you can recreate the problem at that level, it would tell us whether whatever has fixed the problem for current trunk has also been applied to 1.1.X, and thus will be in 1.1.2 when it is released. Unfortunately I can't recreate the problem with either 1.1.1 or the current 1.1.X branch, but then I don't have the same type of machine as you do, and it may be a problem that is specific to a certain build of Python.

If you can recreate on current 1.1.X branch code, then it would also help if you could make the change shown here:

to the django/template/ file. That will reveal where the recursion is happening. Unfortunately due to the way TemplateSyntaxErrors wrap other exceptions, and a change made to Python 2.6, the real traceback where the problem is occurring is currently omitted from the debug information.

Note: See TracTickets for help on using tickets.
Back to Top