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

[mark@…]

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 urls.py 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 fieldset.name %}<h2>{{ fieldset.name }}</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 %}{{ field.field.name }} {% 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>

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

[mark@…]

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

[Karen Tracey]

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?

[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: ​http://dpaste.com/157431/

... 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/basehttp.py", line 280, in run
    self.finish_response()
  File "/usr/lib64/python2.6/site-packages/django/core/servers/basehttp.py", line 320, in finish_response
    self.write(data)
  File "/usr/lib64/python2.6/site-packages/django/core/servers/basehttp.py", line 416, in write
    self._write(data)
  File "/usr/lib64/python2.6/socket.py", line 300, in write
    self.flush()
  File "/usr/lib64/python2.6/socket.py", line 286, in flush
    self._sock.sendall(buffer)
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.

[Karen Tracey]

Replying to mark@tranchant.co.uk:

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 ​http://code.djangoproject.com/svn/django/tags/releases/1.1.1.

If you could switch to an SVN checkout of the 1.1.X branch (​http://code.djangoproject.com/svn/django/branches/releases/1.1.X) 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:

​http://code.djangoproject.com/attachment/ticket/11461/template-fix-lost-traceback.diff

to the django/template/debug.py 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.