Подтвердить что ты не робот

Контрольные точки pydev не работают

Я работаю над проектом с использованием python 2.7.2, sqlalchemy 0.7, unittest, eclipse 3.7.2 и pydev 2.4. Я устанавливаю точки останова в файлах python (unit test files), но они полностью игнорируются (раньше, в какой-то момент они работали). К настоящему моменту я обновил все сопутствующее программное обеспечение (см. Выше), начал новые проекты, играл с настройками, загипнотизировал свой экран, но ничего не работает.

Единственная идея, которую я получил от какой-то должности, заключается в том, что ей есть что-то, что можно изменить имена файлов .py в нижнем регистре.

Есть ли у кого-нибудь идеи?

добавил: Я даже установил aptana-версию eclipse и скопировал файлы .py в it = > тот же результат; точки останова по-прежнему игнорируются.

до сих пор нет прогресса: Я изменил код, который можно рассматривать как необычный, и заменил его более простым решением.

дополнительная информация:, вероятно, что-то связано с модулем unittest:

  • точки останова в моих файлах, определяющие работу тестовых наборов,
  • точки останова в стандартных файлах unittest работают
  • точки останова в моих методах тестирования в классах, полученных из unittest.TestCase не работают
  • точки останова в моем тестируемом коде в тестовых случаях не работают
  • в какой-то момент, прежде чем я смог определить рабочие точки останова в методах тестирования или тестируемый код
  • некоторые вещи, которые я изменил после этого: начали использовать тестовые пакеты, изменили некоторые имена файлов на нижний регистр,...
  • Эта проблема также возникает, если мой код работает без исключений или ошибок тестирования.

Я уже пробовал:

  • удалить .pyc файлы
  • определить новый проект и скопировать только .py файлы в него
  • перезагружается несколько раз между
  • обновлен до eclipse 3.7.2
  • установлен последний pydev на eclipse 3.7.2
  • переключиться на aptana (и обратно)
  • удаленный код, который 'вручную' добавил классы в мой модуль
  • с некоторыми конфигурациями

, что я все еще могу сделать:

  • запустите новый проект с помощью моего кода, начните удалять/изменять код до тех пор, пока не будут работать точки останова, а вид черного ящика - если это имеет какое-то отношение к некоторой части моего кода.

  • Кто-нибудь может понять, что может вызвать эти проблемы или как они могут быть решены?
  • Есть ли другое место для поиска решения?
  • Разрабатывают ли разработчики pydev вопросы по stackoverflow?
  • Есть ли более старая версия pydev, которую я могу попробовать?

Я работал с pydev/eclipse в течение длительного времени, и он хорошо работает для меня, но без отладки я вынужден переключать IDE.

В ответ на вопросы Фабио ниже:

  • Версия python - 2.7.2,
  • sys.gettrace дает None (но я не знаю, что в моем коде может повлиять на это)
  • Это результат отладчика после изменения предложенных параметров:

отладчик 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   <xml><thread name="pydevd.reader" id="-1"/></xml>

sending cmd: CMD_THREAD_CREATE 103  4   <xml><thread name="pydevd.writer" id="-1"/></xml>

('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) ... 

Остальное - вывод unit test.

Продолжая из ответа Fabio часть 2:

Я добавил код в начале программы, и отладчик перестает работать в последней строке, следуя методу в sqlalchemy\orm\attributes.py(это дескриптор, но как или если он мешает отладке не соответствует моим текущим знаниям):

class InstrumentedAttribute (QueryableAttribute):    "" Связанный с классом атрибут атрибута, который добавляет методы дескриптора. ""

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

Оттуда отладчик переходит в метод __getattr__ одного из моих собственных классов, полученный из класса sqlalchemy declarative_base().

Вероятно, решил (хотя и не понял):

Проблема заключалась в том, что упомянутый выше __getattr__ создал нечто похожее на бесконечную рекурсию, однако программа /unittest/sqlalchemy восстановилась без сообщения об ошибке. Я не понимаю код sqlalchemy достаточно, чтобы понять, почему был вызван метод __getattr__.
Я изменил метод __getattr__ на вызов super для имени атрибута, для которого произошла рекурсия (скорее всего, не мое окончательное решение) и проблема с точкой останова. Если я смогу сформулировать проблему консистентно, я, вероятно, попытаюсь получить дополнительную информацию о группе новостей Google sqlalchemy или, по крайней мере, проверить мое решение для надежности.

Спасибо Фабио за вашу поддержку, функция trace_func() выявила проблему для меня.

4b9b3361

Ответ 1

Кажется действительно странным... Мне нужна дополнительная информация, чтобы лучше диагностировать проблему:

Откройте\plugins\org.python.pydev.debug\pysrc\pydevd_constants.py и измените

DEBUG_TRACE_LEVEL = 3 
DEBUG_TRACE_BREAKPOINTS = 3

запустите ваш прецедент с проблемой и добавьте вывод в свой вопрос...

Кроме того, возможно, по какой-то причине средство отладки reset в какой-либо библиотеке, которую вы используете или в вашем коде, выполните следующие действия: в том же месте, в котором вы поставили точку останова:

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

(обратите внимание: при запуске в отладчике ожидалось, что функция трассировки будет выглядеть как: <bound method PyDB.trace_dispatch of <__main__.PyDB instance at 0x01D44878>>)

Также укажите, какую версию Python вы используете.


Ответ части 2:

Тот факт, что sys.gettrace() возвращает None, вероятно, является реальной проблемой... Я знаю некоторые внешние библиотеки, которые с ним работают (например: DecoratorTools - читать: http://pydev.blogspot.com/2007/06/why-cant-pydev-debugger-work-with.html) и даже видели ошибки Python и скомпилированные расширения, нарушающие его...

Тем не менее, самая распространенная причина, по которой он ломается, вероятно, состоит в том, что Python будет молча отключить трассировку (и, следовательно, отладчик), когда рекурсия выдает ошибку (т.е.: RuntimeError: превышена максимальная глубина рекурсии).

Вероятно, вы можете поставить точку останова в самом начале вашей программы и пошаговый отладчик до тех пор, пока он не перестанет работать.

Или, может быть, проще: добавьте код ниже в самое начало вашей программы и посмотрите, как далеко он идет с печатью... Последнее, что напечатано, - это код перед его сломать (так что вы могли бы поставить точка останова на последней строке печатается, зная, что она должна быть последней строкой, где она будет работать) - обратите внимание, что если это большая программа, печать может занять много времени - возможно, даже более быстрая печать в файл вместо консоли (например, cmd, bash или eclipse), а затем открыть этот файл (просто перенаправьте печать из примера в файл).

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)

Если вы все еще не можете понять, пожалуйста, напишите больше информации о полученных результатах...

Примечание: обходной путь, пока вы не найдете фактическое место, использует:

import pydevd;pydevd.settrace()

на том месте, где вы поставили точку останова - таким образом, у вас будет точка останова в коде, которая должна определенно работать, так как она заставит установку трассировки в этот момент (она очень похожа на удалённую отладку: http://pydev.org/manual_adv_remote_debugger.html, за исключением того, что, поскольку отладчик уже был ранее подключен, вам действительно не нужно запускать удаленный отладчик, просто выполните настройку для эмулирования точки останова)

Ответ 2

Поздняя беседа, но на всякий случай это помогает. Я просто столкнулся с подобной проблемой, и обнаружил, что отладчик очень специфичен w.r.t. какие строки он считает "исполняемыми" и доступными для прорыва.

Если вы используете продолжения строки или многострочные выражения (например, внутри списка), поместите контрольную точку в последнюю строку оператора.

Надеюсь, это поможет.

Ответ 3

Попробуйте удалить соответствующий .pyc файл (скомпилированный) и затем запустить. Также я иногда понимал, что у меня запущено более одного экземпляра программы.., который путал pydev.  Я определенно видел это и раньше. Совсем несколько раз.

Ответ 4

Перейдите в аналогичную ситуацию с приложением django в Eclipse/pydev. происходило то, что код, который был запущен, был установлен в моем virtualenv, а не в моем исходном коде. Я удалил свой проект из своих виртуальных веб-пакетов env, перезапустил django в отладчике eclipse/pydev, и все было в порядке.

Ответ 5

У меня были похожие симптомы. Оказалось, что моя последовательность импорта модулей была rexec'ing моего модуля python для точки входа, потому что бинарная (не-Python) библиотека должна была динамически загружаться, то есть LD_LIBRARY_PATH была динамически reset. Я не знаю, почему это заставляет отладчик игнорировать последующие точки останова. Возможно, вызов rexec не указывает debug = true; он должен указать debug = true/false на основе состояния вызывающего контекста?

Попробуйте установить контрольную точку в своем первом операторе импорта, осознавая, что вы затем используете s (tep) или n (ext) для импорта. Когда я буду "дальше" по импорту 3rdparty, требующему динамической загрузки lib, интерпретатор отладки просто продолжит все точки останова.