मुझे GDB

Question

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

मैंने उनसे कहा कि हम -g विकल्प के साथ हमारे कार्यक्रम संकलन कर सकते हैं ताकि के रूप में यह बाइनरी फ़ाइल के लिए डीबगिंग जानकारी जोड़ सकते हैं और कोर डंप फ़ाइल पढ़ सकते हैं, लेकिन फिर साक्षात्कारकर्ता ने मुझे बताया कि अगर वह हम 3 से 4 फ़ाइलें एक साथ संकलित है, लेकिन उनमें से एक के कारण विभाजन गलती तो हम जीडीबी में कैसे डीबग करते हैं?

Answer 1

की तरह वे यह सेट अप करने के लिए इतना है कि आप के रूप में यह चल रहा है कोड के माध्यम से कदम कर सकते हैं देख रहे हैं, तो आप कमांड लाइन संस्करण के साथ ऐसा कर सकते हैं लगता है या मुझे लगता है कि आप GDB के लिए एक जीयूआई मिल सकती है। http://valgrind.org/:

Answer 2

आप लिनक्स के तहत विभाजन गलती खोजने के लिए आसान तरीका काम कर रहे हैं valgrind नामित उपकरण का उपयोग कर रहा है।

आपको बस अपने कोड को -जी ध्वज के साथ संकलित करने की आवश्यकता है और फिर चलाएं ./valgrind।

तो फिर तुम जो समारोह में वास्तव में और कोड की जो लाइन में पता चल जाएगा कि कोई त्रुटि-अप्रारंभीकृत स्मृति/स्मृति आबंटित स्थान या sth से बाहर पढ़ने के लिए है।

Answer 3

$ gcc -ggdb s1.c s2.c s3.c -o myprog 
$ gdb myprog 
(gdb) run --arg1 --arg2 

GDB जब विभाजन दोष होता है GDB इसके शीघ्र वापस करने के लिए छोड़ देंगे और यह एक कोर फाइल के साथ GDB चल के रूप में लगभग एक ही हो जाएगा, सामान्य रूप में कार्यक्रम चलाया जाएगा। मुख्य अंतर यह है कि कुछ ऐसी चीजें हैं जिन्हें आप कोर फ़ाइल के साथ नहीं कर सकते/मुद्रित कर सकते हैं, जब आप जीडीबी के अंदर प्रोग्राम क्रैश हो जाते हैं। (उदाहरण के लिए, प्रोग्राम के अंदर कुछ फ़ंक्शन कॉल करने के लिए आप print का उपयोग कर सकते हैं।)

आप gdb --pid <the programs pid> का उपयोग कर पहले से चल रहे प्रोग्राम से भी संलग्न कर सकते हैं।

या तो एक कोर फाइल के साथ या इसके बाद के तरीकों में से एक के साथ, आप दुर्घटना के बाद GDB शीघ्र जब, प्रकार backtrace (या संक्षेप में bt) और GDB आप ढेर क्रैश के समय जो दिखाएगा सहित, प्रत्येक कॉल के फ़ाइल नाम और लाइन नंबर और वर्तमान में निष्पादन लाइन।

Answer 4

तुम बस gdb के तहत कार्यक्रम, और पकड़ SIGSEGV साथ डिबगर चलाने के लिए और आप लाइन और अनुदेश कि गलती दिखा। फिर आप यह देखने के लिए वैरिएबल और/या रजिस्टर मानों की जांच करें कि क्या गलत है। आम तौर पर यह एक दुष्ट सूचक मूल्य है, और जीडीबी के साथ इसे एक्सेस करने का प्रयास करने से त्रुटि और त्रुटि होगी, इसलिए यह आसान है।

और हां, सबकुछ के साथ सब कुछ recompiling मददगार होगा। साक्षात्कारकर्ता शायद आप यह बताने के लिए चाहते थे कि आप किस फाइल को गलती करते हैं (जीडीबी सिर्फ सिग्नल पकड़ने पर आपको बताता है) और डीबग जानकारी के साथ उसको पुनः संयोजित करें। यदि 20,000 स्रोत फाइलें उपयोगी हो सकती हैं, लेकिन 3 या 4 फाइलों के साथ, बिंदु क्या है? यहां तक ​​कि बड़ी परियोजनाओं के साथ, आप आम तौर पर 10 फंक्शंस और 5 फाइलों के माध्यम से खराब पॉइंटर का पीछा करते हैं, फिर भी, क्या बात है? डीबग जानकारी को रन टाइम पर कुछ भी लागत नहीं है, हालांकि यह एक इंस्टॉलेशन में डिस्क स्पेस खर्च करता है।

Answer 5

जीसीसी फ़ाइल नाम देकर सामान्य तरीके से कोड संकलन आप एक .out फ़ाइल मिल जाएगा, कि प्रदर्शित होने शुरू हो और एक अन्य विंडो प्रकार gdb में ps -aef | grep filename.out

देकर प्रक्रिया आईडी हो और दर्ज करें, gdb शीघ्र दे अंदर attach processid (प्रोसेसिड आप उपरोक्त आदेश से प्राप्त करेंगे), जारी रखने के लिए c दें। निष्पादन खत्म होने पर gdb.you के अंदर "बीटी" दें। आपको वह स्थान मिलेगा जहां सेगमेंटेशन हो रहा है।

Answer 6

एक gdb

$ gdb <exec name > 
$ r   //run the pgm 
$ where 
$ f <1> <0> //to view the function n variables 

$ list 

$ p <variable>