puntos de interrupción pydev no funcionan

Estoy trabajando en un proyecto que utiliza python 2.7.2, sqlalchemy 0.7, unittest, eclipse 3.7.2 y pydev 2.4. Estoy estableciendo puntos de interrupción en los archivos de Python (archivos de prueba de unidad), pero son completamente ignorados (antes, en algún momento, funcionaron). Ya he actualizado todo el software relacionado (ver más arriba), comencé nuevos proyectos, jugué con configuraciones, hipnoticé mi pantalla, pero nada funciona.

La única idea que obtuve de una publicación es que tiene algo que ver con cambiar algunos nombres de archivos .py a minúsculas.

¿Alguien tiene alguna idea?

añadido: incluso instalé la versión aptana de eclipse y copié los archivos .py a él => mismo resultado; Los puntos de interrupción todavía se ignoran.

aún no hay progreso: he cambiado un código que podría parecer inusual y lo reemplacé con una solución más sencilla.

Un poco más de información: probablemente tenga algo que ver con el módulo unittest:

  • los puntos de interrupción en mis archivos que definen las suites de prueba funcionan,
  • Los puntos de interrupción en los archivos unittest estándar funcionan.
  • los puntos de interrupción en mis métodos de prueba en clases derivadas de unittest.TestCase no funcionan
  • Los puntos de interrupción en mi código que se están probando en los casos de prueba no funcionan
  • en algún momento antes de que pudiera definir puntos de interrupción de trabajo en métodos de prueba o el código que se está probando
  • Algunas cosas que cambié después de eso son: comencé a usar suites de prueba, cambié algunos nombres de archivos a minúsculas, …
  • este problema también ocurre si mi código funciona sin excepciones o fallas de prueba.

Lo que ya probé es:

  • eliminar archivos .pyc
  • define un nuevo proyecto y copia solo archivos .py
  • reiniciado varias veces entre
  • actualizado a eclipse 3.7.2
  • instalado el último pydev en eclipse 3.7.2
  • cambiar a aptana (y viceversa)
  • Código eliminado que ‘manualmente’ agregó clases a mi módulo
  • jugueteado con algunas configuraciones

Lo que todavía puedo hacer es:

  • comience un nuevo proyecto con mi código, comience a eliminar / cambiar el código hasta que los puntos de interrupción funcionen y una especie de caja negra puede determinar si esto tiene algo que ver con alguna parte de mi código

  • ¿Alguien tiene alguna idea de qué podría causar estos problemas o cómo podrían resolverse?
  • ¿Hay algún otro lugar donde pueda buscar una solución?
  • ¿Los desarrolladores de pydev examinan las preguntas sobre stackoverflow?
  • ¿Hay alguna versión anterior de pydev que pueda probar?

He estado trabajando con pydev / eclipse durante mucho tiempo y funciona bien para mí, pero sin la depuración, tuve que cambiar IDE.

En respuesta a las preguntas de Fabio a continuación:

  • La versión de python es 2.7.2,
  • El sys.gettrace no da ninguno (pero no tengo idea de lo que en mi código podría influir en eso)
  • Esta es la salida del depurador después de cambiar los parámetros sugeridos:

depurador pydev:

 starting ('Executing file ', 'D:\\.eclipse\\org.eclipse.platform_3.7.0_248562372\\plugins\\org.python.pydev.debug_2.4.0.2012020116\\pysrc\\runfiles.py') ('arguments:', "['D:\\\\.eclipse\\\\org.eclipse.platform_3.7.0_248562372\\\\plugins\\\\org.python.pydev.debug_2.4.0.2012020116\\\\pysrc\\\\runfiles.py', 'D:\\\\Documents\\\\Code\\\\Eclipse\\\\workspace\\\\sqladata\\\\src\\\\unit_test.py', '--port', '49856', '--verbosity', '0']") ('Connecting to ', '127.0.0.1', ':', '49857') ('Connected.',) ('received command ', '501\t1\t1.1') sending cmd: CMD_VERSION 501 1 1.1 sending cmd: CMD_THREAD_CREATE 103 2  sending cmd: CMD_THREAD_CREATE 103 4  ('received command ', '111\t3\tD:\\Documents\\Code\\Eclipse\\workspace\\sqladata\\src\\testData.py\t85\t**FUNC**testAdjacency\tNone') Added breakpoint:d:\documents\code\eclipse\workspace\sqladata\src\testdata.py - line:85 - func_name:testAdjacency ('received command ', '122\t5\t;;') Exceptions to hook : [] ('received command ', '124\t7\t') ('received command ', '101\t9\t') Finding files... done. Importing test modules ... testAtomic (testTypes.TypeTest) ... ok testCyclic (testTypes.TypeTest) ... 

El rest es salida de la prueba unitaria.

Continuando de la respuesta de Fabio parte 2:

He agregado el código al inicio del progtwig y el depurador deja de funcionar en la última línea de seguimiento del método en sqlalchemy \ orm \ attributes.py (es un descriptor, pero cómo o si interfiere con la depuración está más allá de mi conocimiento actual):

clase InstrumentedAttribute (QueryableAttribute): “” “Atributo instrumentado enlazado a la clase que agrega métodos descriptores.” “”

 def __set__(self, instance, value): self.impl.set(instance_state(instance), instance_dict(instance), value, None) def __delete__(self, instance): self.impl.delete(instance_state(instance), instance_dict(instance)) def __get__(self, instance, owner): if instance is None: return self dict_ = instance_dict(instance) if self._supports_population and self.key in dict_: return dict_[self.key] else: return self.impl.get(instance_state(instance),dict_) #<= last line of debugging 

Desde allí, el depurador __getattr__ método __getattr__ de una de mis propias clases, derivado de una clase declarative_base () de sqlalchemy.

Probablemente resuelto (aunque no entendido):

El problema parecía ser que el __getattr__ mencionado anteriormente, creó algo similar a la recursión infinita, sin embargo, el progtwig / unittest / sqlalchemy se recuperó sin reportar ningún error. No entiendo el código sqlalchemy lo suficiente como para entender por qué se __getattr__ método __getattr__ .
Cambié el método __getattr__ para llamar a super para el nombre del atributo para el que se produjo la recursión (probablemente no sea mi solución final) y el problema del punto de interrupción parece haber desaparecido. Si puedo formular el problema de manera consisa, probablemente intentaré obtener más información sobre el grupo de noticias de Google sqlalchemy, o al menos comprobaré si mi solución es robusta.

Gracias Fabio por tu apoyo, la función trace_func () identificó el problema para mí.

Parece realmente extraño … Necesito más información para diagnosticar mejor el problema:

Abra \ plugins \ org.python.pydev.debug \ pysrc \ pydevd_constants.py y cambie

 DEBUG_TRACE_LEVEL = 3 DEBUG_TRACE_BREAKPOINTS = 3 

ejecute su caso de uso con el problema y agregue el resultado a su pregunta …

Además, podría ser que, por algún motivo, el servicio de depuración se reinicie en alguna biblioteca que use o en su código, así que haga lo siguiente: en el mismo lugar donde ubicaría el punto de interrupción:

 import sys print 'current trace function', sys.gettrace() 

(nota: cuando se ejecuta en el depurador, se esperaría que la función de rastreo sea algo así como: > )

Además, por favor publica qué versión de Python estás usando.


Respuesta parte 2:

El hecho de que sys.gettrace () devuelva Ninguno es probablemente el verdadero problema … Sé que algunas bibliotecas externas se meten con él (es decir, DecoratorTools – lee: http://pydev.blogspot.com/2007/06/why -cant-pydev-debugger-work-with.html ) e incluso han visto errores de Python y extensiones comstackdas romperlo …

Aún así, la razón más común por la que se rompe es probablemente porque Python deshabilitará de manera silenciosa el rastreo (y por lo tanto el depurador) cuando una recursión genera un error de desbordamiento de stack (es decir, RuntimeError: se excedió la profundidad máxima de recursión).

Probablemente pueda poner un punto de interrupción al comienzo de su progtwig y pasar al depurador hasta que deje de funcionar.

O tal vez, lo más simple es lo siguiente: agregue el siguiente código al comienzo de su progtwig y vea qué tan lejos llega con la impresión … Lo último que se imprimió es el código justo antes de que se rompiera (por lo tanto, podría poner un punto de interrupción en la última línea impresa, sabiendo que debería ser la última línea donde funcionaría): tenga en cuenta que si se trata de un progtwig grande, la impresión puede llevar mucho tiempo; incluso puede ser una impresión más rápida en un archivo en lugar de una consola (por ejemplo, como cmd, bash o eclipse) y luego abrir ese archivo (solo redirigir la impresión del ejemplo a un archivo).

 import sys def trace_func(frame, event, arg): print 'Context: ', frame.f_code.co_name, '\tFile:', frame.f_code.co_filename, '\tLine:', frame.f_lineno, '\tEvent:', event return trace_func sys.settrace(trace_func) 

Si aún no puede resolverlo, publique más información sobre los resultados obtenidos …

Nota: una solución alternativa hasta que no encuentre el lugar real está utilizando:

 import pydevd;pydevd.settrace() 

en el lugar donde colocaría el punto de interrupción, de esa manera tendría un punto de interrupción en el código que definitivamente debería funcionar, ya que forzará la configuración del servicio de rastreo en ese punto (es muy similar a la depuración remota: http: //pydev.org/manual_adv_remote_debugger.html, excepto que como el depurador ya estaba conectado, no es necesario que inicie el depurador remoto, solo haga el settrace para emular un punto de interrupción)

Llegar tarde a la conversación, pero por si acaso ayuda. Me acabo de encontrar con un problema similar y descubrí que el depurador es muy particular en cuanto a qué líneas considera “ejecutables” y disponibles para interrumpir.

Si está utilizando continuaciones de línea o expresiones de varias líneas (por ejemplo, dentro de una lista), coloque el punto de interrupción en la última línea de la statement.

Espero que ayude.

Intente eliminar el archivo .pyc correspondiente (comstackdo) y luego ejecútelo. También a veces me he dado cuenta de que estaba ejecutando más de una instancia de un progtwig … que confundió a pydev. Definitivamente he visto esto antes también. Bastantes veces.

Se encontró con una situación similar al ejecutar una aplicación django en Eclipse / pydev. Lo que estaba sucediendo era que el código que se estaba ejecutando era el que estaba instalado en mi virtualenv, no en mi código fuente. Eliminé mi proyecto de mis paquetes de sitio de env virtual, reinicié el django en el depurador de eclipse / pydev y todo estuvo bien.

Tenía síntomas similares. Resultó que la secuencia de importación de mi módulo estaba rexecando mi módulo de python de punto de entrada porque una biblioteca binaria (que no es de Python) tenía que cargarse dinámicamente, es decir, el LD_LIBRARY_PATH se restableció dinámicamente. No sé por qué esto hace que el depurador ignore los puntos de interrupción posteriores. Quizás la llamada rexec no esté especificando debug = true; ¿Debería especificar debug = true / false según el estado del contexto de llamada?

Intente establecer un punto de interrupción en su primera statement de importación, ya sea si está entonces (tep) ingresando o n (ext) ‘sobre las importaciones. Cuando “siguiera” sobre la importación de 3rdparty que requería la carga dinámica de lib, el intérprete de depuración simplemente continuaría pasando todos los puntos de interrupción.