लिनक्स पर क्रैश विश्लेषण

Question

लिनक्स पर दुर्घटनाओं का विश्लेषण करने का सबसे अच्छा तरीका क्या है?

हम सॉफ्टवेयर बनाने और परीक्षकों को रिलीज संस्करण देने की उम्मीद करते हैं। परीक्षकों को याद नहीं किया जा सकता है कि दुर्घटना को पुन: उत्पन्न करने के लिए या दुर्घटना पूरी तरह से अस्थायी हो सकती है। उनके पास मशीनों पर विकास वातावरण भी नहीं होगा। सॉफ्टवेयर सी/सी ++ में लिखा गया है और वितरण के लिए मूल मशीन कोड में संकलित किया गया है।

Answer 1

मेरा मानना ​​है कि क्या आप देख रहे हैं यह है: How to generate a stacktrace when my gcc C++ app crashes

Answer 2

आप डिस्क पर जगह है, तो आवेदन जब यह दुर्घटनाओं अपनी coredump बना सकते हैं।

ulimit -c unlimited 

बाद में आप इसे जीडीबी के साथ डीबग कर सकते हैं।

Answer 3

कॉर्डिंग और स्टैकट्रिंग के अलावा पहले से ही नोट किया गया है - सुनिश्चित करें कि आप आसानी से पहचान सकते हैं कि आपके निष्पादन योग्य लोगों के कौन से संस्करण चल रहे हैं, और प्रत्येक स्रोत फ़ाइल का कौन सा संस्करण बाइनरी संस्करण में जाता है (यानी कुछ समय बिताएं आपका स्रोत कोड नियंत्रण प्रणाली और आपकी बिल्ड स्क्रिप्ट)। अन्यथा न तो कोर फ़ाइल और न ही एक स्टैक ट्रेस मदद करने जा रहा है।

Answer 4

कोर डंप सहायक होते हैं, लेकिन वे हमेशा आपको वह सब कुछ नहीं बताते हैं जो आप जानना चाहते हैं कि आप त्रुटि स्थिति में कैसे समाप्त हुए हैं।

लॉगिंग क्रियाएं, इनपुट, और घटनाएं बहुत उपयोगी हो सकती हैं। यदि आप अपने प्रोग्राम के प्रत्येक रन को इस तरह से लॉग इन करने में सक्षम हैं कि किसी क्रैश की स्थिति में डेवलपर लॉग तक पहुंच प्राप्त कर सकता है और त्रुटि पुन: उत्पन्न कर सकता है तो त्रुटि बहुत उपयोगी हो सकती है।

यदि संभव हो तो आपको अपने प्रोग्राम को अधिकतम डीबग प्रतीकों के साथ बनाया जाना चाहिए और फिर उन्हें पट्टी करना चाहिए यदि आप नहीं चाहते हैं या अपने रिलीज़ संस्करणों को उन्हें नहीं दे सकते हैं, लेकिन प्रत्येक रिलीज़ संस्करण की प्रतिलिपि डीबग प्रतीकों के साथ रखें यदि आपको क्रैश डीबग करने की आवश्यकता है तो आप मूल फ़ाइल के साथ जोड़े कर सकते हैं।

Answer 5

generating a stacktrace in a SIGSEGV handler और/या generating a core dump के अतिरिक्त, यह find where an uncaught C++ exception is thrown के लिए भी उपयोगी हो सकता है।