हाँ, उन बेस्टर्ड दुर्घटनाओं को ठीक करने के लिए सबसे कठिन हैं।
सौभाग्य से, कुछ कदम हैं जो आप कर सकते हैं जो आपको कोड को मैन्युअल
रूप से देखने का प्रयास करने से पहले सुराग देगा और सुई ढूंढने की
उम्मीद है।
यह कब दुर्घटनाग्रस्त हो जाता है? हर परीक्षण में? एक विशिष्ट
परीक्षण में? वह परीक्षण क्या करता है कि दूसरों को नहीं?
त्रुटि क्या है? यदि यह एक प्रवेश उल्लंघन है, तो यह कहां होता है
कि यह कहां होता है? यदि पते कम हैं, तो इसका मतलब यह हो सकता है कि
कहीं भी एक अनियंत्रित सूचक है।
क्या प्रोग्राम डीबग कॉन्फ़िगरेशन के साथ क्रैश हो रहा है लेकिन
डीबगर संलग्न किए बिना? यदि ऐसा है, तो जॉन स्मिथर्स ने बताया कि यह
थ्रेड सिंक्रनाइज़ेशन समस्या की सबसे अधिक संभावना है।
क्या आपने पुरीफाई जैसे विश्लेषक के माध्यम से कोड चलाने की कोशिश
की है? यह धीमा है लेकिन यह आमतौर पर प्रतीक्षा के लायक है।
वैसे भी रिलीज विन्यास डीबग करने का प्रयास करें। यह केवल असेंबली
को डंप करेगा लेकिन यह आपको अभी भी संकेत दे सकता है कि क्या होता है
जैसे कि कोड पॉइंटर कचरे के बीच में कूदता है या बाहरी पुस्तकालय में
ब्रेकपॉइंट हिट करता है।
क्या आप इंटेल आर्किटेक्चर पर हैं? यदि नहीं, तो स्मृति संरेखण
त्रुटियों के लिए देखें, वे कुछ आर्किटेक्चर पर चेतावनी के बिना कठिन
क्रैश करते हैं और उन कोडेक एल्गोरिदम उन परिस्थितियों को बहुत अधिक
बनाते हैं क्योंकि वे अत्यधिक अनुकूलित होते हैं।