Как вы автоматизируете запуск / отладку крупномасштабных проектов? - PullRequest
4 голосов
/ 11 апреля 2009

Сценарий:

Существует сложное программное обеспечение, которое раздражает запускать вручную. Я создал скрипт Python для запуска исполняемого файла и прикрепил gdb для отладки.

Сценарий запуска процесса:

  • гарантирует, что переменная окружения установлена.
  • обеспечивает добавление локального каталога сборки в переменную LD_LIBRARY_PATH среды.
  • изменяет текущий рабочий каталог на тот, где должен находиться исполняемый файл (не мой дизайн)
  • запускает исполняемый файл с файлом конфигурации, единственный параметр командной строки
  • направляет вывод из исполняемого файла во второй процесс регистрации
  • запоминает PID исполняемого файла, затем запускает и присоединяет gdb к исполняемому файлу.

Скрипт работает, с одной оговоркой. ctrl-c не прерывает отладчика и не возвращает управление gdb. Так что, если я "продолжаю" без активных точек останова, я никогда не смогу остановить процесс снова, его нужно убить / прервать из другой оболочки. Кстати, запуск "kill -s SIGINT ", где - это pid отладчика, возвращает меня к приглашению GDB ... но это действительно раздражает, когда я так поступаю

Сначала я подумал, что Python захватывает сигнал SIGINT, но, похоже, это не так, поскольку я настраивал обработчики сигналов, которые перенаправляют сигнал отладчику, и это не решает проблему.

Я пробовал различные конфигурации для скрипта Python (вызывая os.spawn * вместо подпроцесса и т. Д.) Кажется, что в любом случае, если Python запустил дочерний процесс, SIGINT (ctrl-c) сигнализирует НЕ перенаправлять на gdb или дочерний процесс.

Текущее мышление

  • Это может быть связано с необходимостью отдельный идентификатор группы процессов для debugee & gdb ... есть ли в этом подтверждение?
  • Возможная ошибка с SELinux?

Информация:

  • ГБД 6,8
  • Python 2.5.2 (проблема присутствует и в Python 2.6.1)
  • Среда SELinux (ошибка доставки сигналов процессам?)

Альтернативы, которые я рассмотрел:

  • Настройка файла .gdbinit для выполнения того же, что и сценарий, переменные окружения и текущий рабочий каталог - проблема этого подхода.
  • Запуск исполняемого файла и присоединение GDB вручную (гадость)

Вопрос: Как вы автоматизируете запуск / отладку крупномасштабных проектов?

Обновление: Я попробовал приведенные ниже примеры Николаса Райли: на моем Macintosh дома все они позволяют cntl-c работать в разной степени, на производственном boxen (который, как я теперь считаю, может работать под SELinux) они не ...

Ответы [ 3 ]

3 голосов
/ 11 апреля 2009

Вместо пересылки сигнала отладчику из Python, вы можете просто проигнорировать его. У меня сработало следующее:

import signal
signal.signal(signal.SIGINT, signal.SIG_IGN)

import subprocess
cat = subprocess.Popen(['cat'])
subprocess.call(['gdb', '--pid=%d' % cat.pid])

Благодаря этому я мог многократно повторять ^ C внутри GDB и без проблем прерывать отладчика, однако я видел странное поведение.

Кстати, у меня тоже не было проблем при пересылке сигнала целевому процессу.

import subprocess
cat = subprocess.Popen(['cat'])

import signal, os
signal.signal(signal.SIGINT,
              lambda signum, frame: os.kill(cat.pid, signum))

subprocess.call(['gdb', '--pid=%d' % cat.pid])

Так, может, что-то еще происходит в вашем случае? Это может помочь, если вы разместили код, который ломается.

0 голосов
/ 16 апреля 2009

если у вас уже есть текущий сценарий, настроенный для этого, но у вас есть проблемы с автоматизацией его части, возможно, вы можете просто получить ожидаемый результат и использовать его для настройки, а затем вернуться в интерактивный режим, чтобы запустить процесс. Тогда у вас все еще может быть ваш ctrl-c для прерывания.

0 голосов
/ 15 апреля 2009

В вашем комментарии отмечается, что вы добавляете шпатлевку ... у вас есть контрольный tty? С openssh вы захотите добавить опцию -T, я не знаю, как / если замазка сделает это так, как вы ее используете.

Также: вы можете попробовать использовать ssh Cygwin вместо putty.

...