#12843 closed (worksforme)
add user in admin causes template exception: maximum recursion depth exceeded
Reported by: | 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 |
Description
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>
Change History (5)
comment:1 by , 15 years ago
comment:3 by , 15 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
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?
follow-up: 5 comment:4 by , 15 years ago
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.
comment:5 by , 15 years ago
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.
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.