[Django] #21348: RuntimeError: maximum recursion depth exceeded while calling a Python object

130 views
Skip to first unread message

Django

unread,
Oct 28, 2013, 10:58:52 PM10/28/13
to django-...@googlegroups.com
#21348: RuntimeError: maximum recursion depth exceeded while calling a Python
object
----------------------------------------------+----------------------------
Reporter: un33k | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) | Version: master
Severity: Release blocker | Keywords: recursion
Triage Stage: Unreviewed | depth
Easy pickings: 0 | Has patch: 0
| UI/UX: 0
----------------------------------------------+----------------------------
'''Sample project to take Django 1.6 for a spin.
'''
Project works well with 1.6b4 and runs into the following problem as soon
as I upgrade to 1.6c1.

'''Env''':
1. Linux Ubuntu 12.04
2. Python 2.7.3
3. Sqlite3
4. Django 1.6c1

'''Done''':
1. Did a diff of tags: 1.6b4 and 1.6c1 and nothing jump out at me.
2. Searched Google and djangoproject.com for a duplicate ticket or a
possible fix. No result!

Creating the ticket to share my finding for speedier clouser.

Note: There is no 1.6-rc-1 yet, hence setting version to Master.

Please review and share you thoughts on this.

Thanks


'''---- LOG ----
'''
RuntimeError
RuntimeError: maximum recursion depth exceeded while calling a Python
object

Traceback (most recent call last)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/dozer/leak.py", line 111, in __call__
return self.app(environ, start_response)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/contrib/staticfiles/handlers.py", line 67, in __call__
return self.application(environ, start_response)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/core/handlers/wsgi.py", line 206, in __call__
response = self.get_response(request)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/core/handlers/base.py", line 196, in get_response
response = self.handle_uncaught_exception(request, resolver,
sys.exc_info())
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/core/handlers/base.py", line 231, in
handle_uncaught_exception
return debug.technical_500_response(request, *exc_info)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/core/handlers/base.py", line 90, in get_response
response = middleware_method(request)
File
"/mnt/hgfs/Projects/workon/web/djangoware/djangoware/apps/userware/middleware/logout.py",
line 14, in process_request
if request.user.is_authenticated():
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/utils/functional.py", line 213, in inner
self._setup()
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/utils/functional.py", line 298, in _setup
self._wrapped = self._setupfunc()
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/contrib/auth/middleware.py", line 18, in <lambda>
request.user = SimpleLazyObject(lambda: get_user(request))
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/contrib/auth/middleware.py", line 10, in get_user
request._cached_user = auth.get_user(request)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/contrib/auth/__init__.py", line 137, in get_user
user = backend.get_user(user_id) or AnonymousUser()
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/contrib/auth/backends.py", line 69, in get_user
return UserModel._default_manager.get(pk=user_id)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/models/manager.py", line 151, in get
return self.get_queryset().get(*args, **kwargs)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/models/query.py", line 301, in get
num = len(clone)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/models/query.py", line 77, in __len__
self._fetch_all()
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/models/query.py", line 854, in _fetch_all
self._result_cache = list(self.iterator())
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/models/query.py", line 220, in iterator
for row in compiler.results_iter():
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/models/sql/compiler.py", line 710, in results_iter
for rows in self.execute_sql(MULTI):
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/models/sql/compiler.py", line 781, in execute_sql
cursor.execute(sql, params)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/devserver/modules/sql.py", line 77, in execute
return super(DatabaseStatTracker, self).execute(sql, params)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/backends/util.py", line 69, in execute
return super(CursorDebugWrapper, self).execute(sql, params)

............. hundreds of recursion on line 69 as above
...................

File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/backends/util.py", line 69, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/backends/util.py", line 73, in execute
sql = self.db.ops.last_executed_query(self.cursor, sql, params)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/backends/__init__.py", line 854, in last_executed_query
u_params = tuple(to_unicode(val) for val in params)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/backends/__init__.py", line 854, in <genexpr>
u_params = tuple(to_unicode(val) for val in params)
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/db/backends/__init__.py", line 852, in <lambda>
to_unicode = lambda s: force_text(s, strings_only=True, errors='replace')
File "/mnt/hgfs/Projects/.web-virenv/djangoware/lib/python2.7/site-
packages/django/utils/encoding.py", line 93, in force_text
if isinstance(s, six.text_type):
RuntimeError: maximum recursion depth exceeded while calling a Python
object
The debugger caught an exception in your WSGI application. You can now
look at the traceback which led to the error.
To switch between the interactive traceback and the plaintext one, you can
click on the "Traceback" headline. From the text traceback you can also
create a paste of it. For code execution mouse-over the frame you want to
debug and click on the console icon on the right side.

You can execute arbitrary Python code in the stack frames and there are
some extra helpers available for introspection:

dump() shows all variables in the frame
dump(obj) dumps all that's known about the object

--
Ticket URL: <https://code.djangoproject.com/ticket/21348>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Oct 29, 2013, 1:18:25 AM10/29/13
to django-...@googlegroups.com
#21348: RuntimeError: maximum recursion depth exceeded while calling a Python
object
-------------------------------------+-------------------------------------

Reporter: un33k | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Release blocker | Triage Stage:
Keywords: recursion depth | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by akaariai):

* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0


Comment:

It seems you are using django-devserver (https://github.com/dcramer
/django-devserver/). My guess is that django-devserver's
DatabaseStatTracker (a DebugCursorWrapper subclass) and changes in
0d74bdaf0c39feb8ec303dbbdbcadba70e46eecb do not interact well.

With the information available it seems very likely that this is an error
in django-devserver, not in Django itself. Having a call "return
super(CursorDebugWrapper, self).execute(sql, params)" recurse indefinitely
should not happen unless there is monkey-patching going on...

--
Ticket URL: <https://code.djangoproject.com/ticket/21348#comment:1>

Django

unread,
Oct 29, 2013, 11:26:16 AM10/29/13
to django-...@googlegroups.com
#21348: RuntimeError: maximum recursion depth exceeded while calling a Python
object
-------------------------------------+-------------------------------------

Reporter: un33k | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Release blocker | Triage Stage:
Keywords: recursion depth | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by un33k):

I have tested and now can '''confirm''' that the cause of the error is
indeed django-devserver (0.7.0).

I cannot confirm any monkey-patching, so perhaps we leave the ticket
"open" for the time being?

--
Ticket URL: <https://code.djangoproject.com/ticket/21348#comment:2>

Django

unread,
Oct 29, 2013, 11:33:59 AM10/29/13
to django-...@googlegroups.com
#21348: RuntimeError: maximum recursion depth exceeded while calling a Python
object
-------------------------------------+-------------------------------------

Reporter: un33k | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:

Keywords: recursion depth | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by akaariai):

* severity: Release blocker => Normal


Comment:

OK for me. But I'll remove the release blocker.

--
Ticket URL: <https://code.djangoproject.com/ticket/21348#comment:3>

Django

unread,
Oct 29, 2013, 1:47:33 PM10/29/13
to django-...@googlegroups.com
#21348: RuntimeError: maximum recursion depth exceeded while calling a Python
object
-------------------------------------+-------------------------------------

Reporter: un33k | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: recursion depth | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by dcramer):

* cc: dcramer@… (added)


Comment:

This likely breaks a ton of injection stuff thats out there (probably all
written by me, so I take blame). I didn't really dig into it too much yet,
but nothing was obvious in my 5 seconds spent looking at the code.

--
Ticket URL: <https://code.djangoproject.com/ticket/21348#comment:4>

Django

unread,
Nov 4, 2013, 8:00:17 AM11/4/13
to django-...@googlegroups.com
#21348: RuntimeError: maximum recursion depth exceeded while calling a Python
object
-------------------------------------+-------------------------------------
Reporter: un33k | Owner: nobody
Type: Bug | Status: closed

Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix

Severity: Normal | Triage Stage:
Keywords: recursion depth | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by akaariai):

* status: new => closed
* resolution: => wontfix


Comment:

It isn't good that django-devserver is broken. But Django must be able to
assume that super(CursorDebugWrapper, self).execute(...) really calls the
super method, not the calling method again.

--
Ticket URL: <https://code.djangoproject.com/ticket/21348#comment:5>

Django

unread,
Nov 6, 2013, 4:06:52 PM11/6/13
to django-...@googlegroups.com
#21348: RuntimeError: maximum recursion depth exceeded while calling a Python
object
-------------------------------------+-------------------------------------
Reporter: un33k | Owner: nobody

Type: Bug | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: recursion depth | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by kosz85@…):

It happen in devserver when you don't have debug_toolbar, then in throw
ImportError and your DatabaseStatTracker will iherit from
CursorDebugWrapper. '''It's not django error'''.

I checked and it is monkeypatching. They inherit from CursorDebugWrapper,
and store as old class, but thay change util.CursorDebugWrapper to point
DatabaseStatTracker, so when it go to CursorDebugWrapper and call super,
this name point to DatabaseStatTracker so its like:
super(CursorDebugWrapper, slef) == super(DatabaseStatTracker, self) so it
loops. There would help some kind of settings to overwrite default
CursorWrapper without monkeypatching which like you see is risky.

If you need it badly just rename at line 26 CursorDebugWrapper to
CursorWrapper, then it won't crash when using CursorDebugWrapper.

--
Ticket URL: <https://code.djangoproject.com/ticket/21348#comment:6>

Django

unread,
Nov 6, 2013, 4:07:25 PM11/6/13
to django-...@googlegroups.com
#21348: RuntimeError: maximum recursion depth exceeded while calling a Python
object
-------------------------------------+-------------------------------------
Reporter: un33k | Owner: nobody

Type: Bug | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: recursion depth | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by anonymous):

sorry line 52 ;)

--
Ticket URL: <https://code.djangoproject.com/ticket/21348#comment:7>

Django

unread,
Jan 3, 2014, 5:45:51 PM1/3/14
to django-...@googlegroups.com
#21348: RuntimeError: maximum recursion depth exceeded while calling a Python
object
-------------------------------------+-------------------------------------
Reporter: un33k | Owner: nobody

Type: Bug | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: recursion depth | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by beau@…):

There's now an [https://github.com/dcramer/django-devserver/pull/96 open
pull request in django-devserver] that fixes this issue.

--
Ticket URL: <https://code.djangoproject.com/ticket/21348#comment:8>

Django

unread,
May 2, 2014, 3:16:28 PM5/2/14
to django-...@googlegroups.com
#21348: RuntimeError: maximum recursion depth exceeded while calling a Python
object
-------------------------------------+-------------------------------------
Reporter: un33k | Owner: nobody

Type: Bug | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: recursion depth | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by foxwhisper):

This has now been fixed in devserver `0.8.0`.

--
Ticket URL: <https://code.djangoproject.com/ticket/21348#comment:9>

Reply all
Reply to author
Forward
0 new messages