2010-02-15 13 views
14

जीडीबी का उपयोग करते हुए कोर डंप को डीबग करने के लिए 'सर्वोत्तम प्रथाओं' क्या हैं?कोर डंप का उपयोग कर लिनक्स में डिबगिंग

वर्तमान में, मैं एक समस्या का सामना करना पड़ रहा हूँ:

  • अपने आवेदन की रिलीज़ संस्करण 'जी' संकलक झंडा बिना संकलित किया गया है।
  • मेरे आवेदन का डीबग संस्करण ('-g' के साथ संकलित) संग्रहीत किया गया है (स्रोत कोड के साथ, और रिलीज बाइनरी की एक प्रति)।

हाल ही में, जब कोई उपयोगकर्ता मुझे एक कोर डंप दिया था, मैं इसे

gdb --core=./core.pid ./my_app_debug-bin 

कोर my_app_release-bin द्वारा बनाया गया था का उपयोग कर डिबगिंग की कोशिश की। कोर फ़ाइल और बाइनरी के बीच कुछ प्रकार का मेल नहीं लगता है।

दूसरी ओर, अगर मैं

gdb --core=./core.pid ./my_app_release-bin 

कोर मैचों की कोशिश, लेकिन मैं स्रोत कोड लाइन नंबर प्राप्त करने में असमर्थ हूँ (हालांकि मैं समारोह नाम प्राप्त)।

क्या यह अभ्यास किया जाता है? क्योंकि मुझे लगता है कि मैं यहाँ कुछ याद कर रहा हूँ।

+1

प्रश्न शीर्षक में अच्छा अतिरिक्त टैगिंग, मेरा मतलब है कि ऐसा नहीं है कि एसओ ने टैगिंग में अंतर्निहित किया है ... –

उत्तर

16

ऐसा लगता है कि आपकी रिलीज और डिबग बिल्ड के बीच अन्य अंतर हैं, तो बस -g ध्वज की अनुपस्थिति/उपस्थिति। मान लीजिए कि ऐसा कुछ भी नहीं है, आप अभी कुछ भी नहीं कर सकते हैं, लेकिन आप इसे बेहतर तरीके से संभालने के लिए अपने निर्माण को समायोजित कर सकते हैं:

यहां हम अपने काम के स्थान पर क्या करते हैं।

  1. रिलीज संस्करण बनाने के दौरान -g ध्वज शामिल करें।
  2. उस संस्करण को संग्रहीत करें।
  3. ग्राहकों को शिपिंग करने से पहले बाइनरी पर strip --strip-unneeded चलाएं।

अब, जब हमें दुर्घटना हो जाती है तो हम संग्रहित संस्करण का उपयोग डिबगिंग करने के लिए प्रतीकों के साथ कर सकते हैं।

ध्यान देने योग्य एक बात यह है कि यदि आपके रिलीज़ संस्करण में अनुकूलन शामिल है, तो डिबगिंग प्रतीकों के साथ भी मुश्किल हो सकती है। उदाहरण के लिए, ऑप्टिमाइज़र आपके कोड को पुन: व्यवस्थित कर सकता है, भले ही डीबगर कहता है कि आप लाइन एन पर दुर्घटनाग्रस्त हो गए हैं, आप यह नहीं मान सकते कि कोड वास्तव में लाइन एन-1 निष्पादित किया गया है।

+0

अरे सैमुअल, यह सोचने का सही तरीका है, मुझे लगता है। यहां तक ​​कि @ माइकल ने भी इसी तरह के समाधान की ओर इशारा किया। हालांकि, डीबग/रिलीज बाइनरी में केवल अंतर का अंतर होता है। मैक्रोज़ _DEBUG (डीबग के लिए) और एनडीईबीयूजी (रिलीज के लिए) भी है। शायद यह मुद्दा पैदा कर रहा है? वैसे भी, मैं अलग-अलग बाइनरी का पता लगाने की योजना बना रहा हूं। धन्यवाद! – themoondothshine

+0

बीटीडब्ल्यू, क्या आप 'addr2line' टूल के बारे में कुछ जानते हैं? मुझे इसके अस्पष्ट संदर्भ मिले। यह स्रोत कोड दिए गए पते को लाइन नंबरों में कनवर्ट करने में सक्षम होना चाहिए। मेरे पास पहले से ही फ़ंक्शन पते हैं, मुझे केवल स्रोत कोड के लिए मैपिंग की आवश्यकता है ... – themoondothshine

+0

@themoondothshine: जीडीबी आपके लिए यह कर सकता है (जब तक यह डीबग प्रतीक है), 'जानकारी लाइन * 0xsomeaddr' – Hasturkun

1

नहीं, आपको कुछ भी याद नहीं है। डीबग और रिलीज सिर्फ अलग-अलग बाइनरी हैं, इसलिए रिलीज की मूल फाइलें डिबग बाइनरी से मेल नहीं खाती हैं। रिलीज कोर डंप से कुछ प्राप्त करने के लिए आपको मशीन कोड देखना होगा।

आपको शायद अपने उपयोगकर्ता से पूछना होगा कि दुर्घटना कैसे हुई और अतिरिक्त लॉग जानकारी एकत्र करें या जो भी आप ऐप तैयार करते हैं।

+0

हे नोडन, मैं पहले से ही एप्लिकेशन में बहुत सारी जानकारी लॉग करता हूं, लेकिन कभी-कभी यह काफी पर्याप्त नहीं हो सकता है। उपयोगकर्ता अक्सर यह नहीं जानते कि क्रैश का कारण क्या है क्योंकि यह पृष्ठभूमि प्रक्रिया के रूप में चलता है। मेरे पास 'addr2line' टूल पर कुछ और जानकारी भी है। मुझे लगता है कि मैं उसे भी कोशिश करूंगा। – themoondothshine

5

आपको स्ट्रिप डीबग जानकारी के साथ द्विआधारी बनाने के लिए कुछ अतिरिक्त सामान करने की आवश्यकता है जिसे आप कोर से डीबग कर सकते हैं। मुझे सबसे अच्छा विवरण मिल सकता है here

+0

हे माइकल, लिंक के लिए धन्यवाद। यह वास्तव में सहायक था। – themoondothshine

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