كيف تقوم بأتمتة إطلاق / تصحيح الأخطاء من المشاريع الكبيرة؟

Question

سيناريو:

هناك قطعة معقدة من البرامج مزعجة للإطلاق باليد. ما قمت به هو إنشاء برنامج نصي بيثون لإطلاق القابل للتنفيذ وإرفاقه GDB لتصحيح الأخطاء.

البرنامج النصي لإطلاق البرنامج:

• يضمن تم تعيين متغير بيئة.
• يضمن إضافة دليل بناء محلي إلى البيئة LD_LIBRARY_PATH عامل.
• يغير دليل العمل الحالي إلى حيث يتوقع التنفيذ أن يكون (ليس تصميمي)
• تطلق الملف القابل للتنفيذ مع ملف التكوين خيار سطر الأوامر الوحيد
• أنابيب الإخراج من الملف القابل للتنفيذ إلى عملية تسجيل ثانية
• يتذكر PID القابل للتنفيذ، ثم يطلق GDB لتشغيل الملف القابل للتنفيذ.

يعمل البرنامج النصي، مع تحذير واحد. لا تقاطع CTRL-C Debugee وعودة التحكم إلى GDB. لذلك إذا كنت "متابعة" مع عدم وجود نقاط توقف نشطة لا أستطيع إيقاف العملية مرة أخرى، يجب أن يقتل / توقف من قذيفة أخرى. راجع للشغل، تشغيل "Kill-Sigintu003Cpid> " أينu003Cpid> هل تعيدني PID Debuggee إلى موجه GDB ... ولكن من المزعج حقا أن أفعل أشياء بهذه الطريقة

في البداية اعتقدت أن بيثون تم الاستيلاء على إشارة Sigint، ولكن هذا لا يبدو أن هذا هو الحال لأنني أقوم بإعداد معالجات الإشارة إلى الأمام الإشارة إلى DeBugee وهذا لا يحل المشكلة.

لقد جربت العديد من التكوينات إلى البرنامج النصي Python (استدعاء OS.Spawn * بدلا من الإعانات الفرعية، وما إلى ذلك) يبدو أن أي طريقة أذهب حولها، إذا أطلقت Python عملية الطفل، Sigint (CTRL-C) الإشارات لا تفعل ذلك الحصول على توجيه إلى GDB أو عملية الطفل.

خط التفكير الحالي

• قد يكون هذا مرتبطا بالحاجة إلى معرف مجموعة منفصلة لعملية Debugee & GDB ... أي مصادقة على هذا؟
• علة محتملة مع Selinux؟

معلومات:

• GDB 6.8.
• بيثون 2.5.2 (مشكلة موجودة مع بيثون 2.6.1 كذلك)
• بيئة Selinux (علة تسليم الإشارات إلى العمليات؟)

البدائل التي نظرت فيها:

• إعداد ملف .gdbinit للقيام به أكبر قدر ممكن من البرنامج النصي، ومتغيرات البيئة ودليل العمل الحالي مشكلة في هذا النهج.
• إطلاق الملف القابل للتنفيذ وإرفاق GDB يدويا (Yuck)

سؤال:كيف تقوم بأتمتة إطلاق / تصحيح الأخطاء من المشاريع الكبيرة؟

تحديث:لقد جربت أمثلة نيكولاس رايلي أدناه، على Macintosh في المنزل، فإنها تسمح جميعا CNTL-C للعمل بدرجات مختلفة، على Boxen الإنتاج (الذي أصدقه الآن قد يكون قيد التشغيل Selinux).

Answer 1

بدلا من إعادة توجيه الإشارة إلى Debuggee من بيثون، يمكنك محاولة تجاهلها فقط. ما يلي يعمل بالنسبة لي:

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])

لذلك، ربما شيء آخر يجري في قضيتك؟ قد يساعده إذا قمت بنشر بعض الكود الذي يكسر.

Answer 2

تلاحظ تعليقك أنك ستقامس مع المعجون ... هل لديك TTY التحكم؟ مع Openssh، كنت ترغب في إضافة خيار -T، لا أعرف كيف / إذا ستفعل المعجون هذه الطريقة التي تستخدمها.

أيضا: قد تحاول استخدام Cygwin's SSH بدلا من المعجون.

Answer 3

إذا كان لديك بالفعل البرنامج النصي الحالي إعداده للقيام بذلك، ولكنه تواجه مشكلات لأتمتة جزء منه، فربما يمكنك فقط الاستيلاء على توقع واستخدامه لتوفير الإعداد، ثم الرجوع إلى وضع تفاعلي في توقع تشغيل العملية. ثم لا يزال بإمكانك الحصول على CTRL-C الخاص بك للمقاطعة.