2010-01-12 4 views
7

मैं जीडीबी के साथ लिखा एक सर्वर डीबग करने की कोशिश कर रहा हूं क्योंकि यह बहुत विशिष्ट और दुर्लभ स्थितियों के तहत segfaults है।पृष्ठभूमि में एक डेमॉन के खिलाफ gdb कैसे चलाएं?

क्या कोई तरीका है कि मैं पृष्ठभूमि में जीडीबी चला सकता हूं (शांत या बैच मोड के माध्यम से?), बच्चों का पालन करें (क्योंकि मेरा सर्वर एक डीमन और मुख्य पीआईडी ​​से अलग है) और स्वचालित रूप से कोर और बैकट्रैस को डंप करता है (एक बार नामित फाइल के लिए) एक बार कार्यक्रम दुर्घटनाग्रस्त हो जाता है?

+0

http: // stackoverflow।कॉम/प्रश्न/17 9 65/जेनरेट-ए-कोर-डंप-इन-लिनक्स कोर डंप –

+0

@ हसन साइड के बारे में SO पोस्ट: http://vmlinux.org/jocke/mirror/www.objsw.com/docs/gdb_22.html एक मृत लिंक है। – bgoodr

उत्तर

6

क्यों न सिर्फ प्रक्रिया सहभागी एक लगातार स्क्रीन सत्र में चला सकता हूँ? डीबगिंग करते समय यह एक डिमन क्यों होना चाहिए? या बस स्क्रीन सत्र में gdb चलाएं और इसे फोर्क के बाद चलने की प्रक्रिया (उदा। Gdb/path/to/binary -p pID_of_binary) से संलग्न करें।

+0

यह वास्तव में एक अच्छा विचार है, कोई विचार नहीं कि मैंने इस बारे में क्यों नहीं सोचा: पी प्राथमिक समाधान के लिए धन्यवाद! स्क्रीन के बजाय tmux के लिए –

+0

+1 – lkraav

1

मैं वास्तव में नहीं एक gdb विशेषज्ञ लेकिन यह चल रहा है, जबकि दो बातें दिमाग में

  1. Tracepoints के रूप में अपने कार्यक्रम चलाता है जो आप आवश्यक जानकारी दे सकता है या
  2. gdb के remote debugging facility उपयोग अपने कार्यक्रम डिबग करने के लिए आ रहा हूँ एक डेमॉन के रूप में।
3

सबसे पहले, मैं आपको कोर डंप देने के लिए अपना खोल/पर्यावरण सेट अप करूंगा।

ulimit -c unlimited 

एक बार जब आप कोर डंप है, तो आप स्टैक ट्रेस की जांच करने के gdb उपयोग कर सकते हैं: बैश में

gdb /path/to/app /path/to/core/file 
+2

ध्यान दें कि मूल फ़ाइल होने के समान ही एक ही प्रक्रिया नहीं है क्योंकि डीबगर के तहत एक ही प्रक्रिया बंद हो गई है। कोर फ़ाइल ओपन फाइल डिस्क्रिप्टर या मेमोरी मैपिंग स्टेटस के बारे में जानकारी को सुरक्षित नहीं रखती है। तो यह हमेशा एक उपयोगी सुझाव नहीं है। –

+1

और आप प्रोग्राम में परिभाषित कार्यों को कॉल नहीं कर सकते हैं। –

7

मान लें कि आपके पास उचित अनुमतियां हैं, तो आप किसी भी प्रक्रिया से जीडीबी संलग्न कर सकते हैं। संलग्न कमांड के साथ

gdb /path/to/binary _pid_ 

या से gdb के भीतर:: आप के साथ कमांड लाइन पर यह कर सकते हैं

attach _pid_ 

तो, एक बार अपने डेमॉन शुरू कर दिया है, तो आप इन तकनीकों के दोनों संलग्न करने के लिए उपयोग कर सकते हैं अंतिम पीआईडी ​​के लिए आपका डिमन चल रहा है। संलग्न जीडीबी उस प्रक्रिया को रोकता है जिसे आप ट्रेस कर रहे हैं ताकि आपको इसे पुनरारंभ करने के लिए "जारी रखें" जारी करना होगा।

प्रोग्राम क्रैश होने पर जीडीबी को मनमाने ढंग से कमांड चलाने के लिए सीधा तरीका नहीं पता है। यहां एक कामकाज है जिसके बारे में मैं सोच सकता हूं:

  1. SIGSEGV के लिए सिग्नल हैंडलर बनाएं और पंजीकृत करें।
  2. बताएं कि जीडीबी उस सिग्नल पर नहीं रुकें (handle SIGSEGV nostop)
  3. अपने सिग्नल हैंडलर की पहली पंक्ति में ब्रेकपॉइंट सेट करें।
  4. असाइन commands to the breakpoint कदम से 3
1

आप कैसे सांबा की सुविधा डिबगिंग पर एक नज़र लेने के लिए चाहते हो सकता है; इसमें एक कॉन्फ़िगर करने योग्य "panic action" है जो एप्लिकेशन को निलंबित कर सकता है, डेवलपर को सूचित कर सकता है, स्पॉन जीडीबी इत्यादि, और इसके सिग्नल हैंडलर के हिस्से के रूप में चलाया जा सकता है। सांबा स्रोत पेड़ में lib/util/fault.c देखें।

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^