Django excepción me molesta, no saben cómo depurar que

Question

Recientemente he actualizado a python2.7 y django1.3 y desde entonces

Unhandled exception in thread started by <bound method Command.inner_run of <django.core.management.commands.runserver.Command object at 0x109c57490>> 
Traceback (most recent call last): 
    File "/Users/ApPeL/.virtualenvs/myhunt/lib/python2.7/site-packages/django/core/management/commands/runserver.py", line 88, in inner_run 
     self.validate(display_num_errors=True) 
    File "/Users/ApPeL/.virtualenvs/myhunt/lib/python2.7/site-packages/django/core/management/base.py", line 249, in validate 
     num_errors = get_validation_errors(s, app) 
    File "/Users/ApPeL/.virtualenvs/myhunt/lib/python2.7/site-packages/django/core/management/validation.py", line 36, in get_validation_errors 
     for (app_name, error) in get_app_errors().items(): 
    File "/Users/ApPeL/.virtualenvs/myhunt/lib/python2.7/site-packages/django/db/models/loading.py", line 146, in get_app_errors 
     self._populate() 
    File "/Users/ApPeL/.virtualenvs/myhunt/lib/python2.7/site-packages/django/db/models/loading.py", line 67, in _populate 
     self.write_lock.release() 
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 137, in release 
     raise RuntimeError("cannot release un-acquired lock") 
    RuntimeError: cannot release un-acquired lock 

Su ayuda sería muy apreciada.

Answer 1

Una primera recomendación habitual es aplicar las últimas actualizaciones a gevent o greenlet o lo que utilice relacionado con los hilos. Implementación de threading.Thread.start se ha cambiado entre Python 2.6 y 2.7. Hay muchas recetas de cómo empezar en verde ... o verde ... con Django. Intenta leer cualquier reciente para Python 2.7. y envía un enlace que hace el problema.

Depuración: Agregar siguientes líneas a su manage.py para habilitar el registro de inicio de tema, etc. salida estándar de errores:

import threading 
setattr(threading, '__debug__', True) 

Añadir el argumento verbosedjango/db/loading.py a la línea 39 con el fin de ver también lo que adquieren y las discusiones suelta el candado

-  write_lock = threading.RLock(), 
+  write_lock = threading.RLock(verbose=True), 

Ejecute el servidor de desarrollo. Por sólo un hilo sin autoreload debería ver algo como:

$ python manage.py runserver --noreload 
Validating models... 

MainThread: <_RLock owner='MainThread' count=1>.acquire(1): initial success 
MainThread: <_RLock owner=None count=0>.release(): final release 

Notas:
count=1 acquire(1) - la primera adquisición por una cerradura de bloqueo
owner=None count=0>.release() - la la cerradura se desbloquea Actualmente

$ python manage.py runserver 
Validating models... 

Dummy-1: <_RLock owner=-1222960272 count=1>.acquire(1): initial success 
Dummy-1: <_RLock owner=None count=0>.release(): final release 

Esto es lo mismo con autorecarga. Los modelos son validados por el proceso hijo. "Dummy-1" es un nombre simbólico del hilo. Esto puede repetirse para más subprocesos, pero ningún subproceso debe/puede adquirir el bloqueo hasta que lo libere el subproceso anterior. Podemos continuar según los resultados.