पहली बात के लिए देखने के लिए त्रुटि संदेश है कि आप जब कार्यक्रम दुर्घटनाओं प्राप्त है। यह अक्सर आपको बताएगा कि किस प्रकार की त्रुटि हुई। उदाहरण के लिए "विभाजन गलती" या "SIGSEGV" लगभग निश्चित रूप से इसका अर्थ है कि आपके प्रोग्राम ने एक पूर्ण या अन्यथा अमान्य सूचक का संदर्भ दिया है। यदि कार्यक्रम सी ++ में लिखा गया है, तो त्रुटि संदेश अक्सर आपको किसी भी अपरिपक्व अपवाद का नाम बताएगा।
यदि आपको त्रुटि संदेश नहीं दिखाई दे रहा है, तो प्रोग्राम को कमांड लाइन से चलाएं, या उसके आउटपुट को फ़ाइल में पाइप करें।
कोर फ़ाइल वास्तव में उपयोगी होने के लिए, आपको अनुकूलन के बिना और डिबगिंग जानकारी के बिना अपने प्रोग्राम को संकलित करने की आवश्यकता है। जीसीसी को निम्नलिखित विकल्पों की आवश्यकता है: -g -O0। (सुनिश्चित करें कि आपके निर्माण में कोई अन्य -O विकल्प नहीं है।बिंदु जहां दुर्घटना हुई देखने के लिए
gdb YOUR-APP COREFILE
प्रकार where:)
एक बार जब आप मूल फ़ाइल है, तो यह gdb में खोलने के साथ। आप मूल रूप से एक सामान्य डीबगिंग सत्र में हैं - आप वैरिएबल की जांच कर सकते हैं, स्टैक को ऊपर और नीचे ले जा सकते हैं, थ्रेड और जो भी हो, के बीच स्विच कर सकते हैं।
यदि आपका प्रोग्राम क्रैश हो गया है, तो शायद यह एक अवैध स्मृति पहुंच है - इसलिए आपको उस पॉइंटर की तलाश करनी होगी जिसमें शून्य-मूल्य है, या वह खराब दिखने वाले डेटा को इंगित करता है। आपको ढेर के बहुत नीचे समस्या नहीं मिल सकती है, आपको समस्या को ढूंढने से पहले आपको कुछ स्तरों को ढेर करना पड़ सकता है।
शुभकामनाएं!
स्रोत
2009-09-26 21:32:18
आपके विस्तृत उत्तर के लिए धन्यवाद। सर्वर को डीबगिंग जानकारी के साथ संकलित किया गया है और जब यह दुर्घटनाग्रस्त हो जाता है तो कोर डंप बनाता है। सर्वर कई धागे शुरू करता है। जब भी धागे 200 से कम होते हैं तो सर्वर एक घंटे से थोड़ा अधिक समय तक काम करता रहता है लेकिन जब अनुरोधों की संख्या में वृद्धि पूल में धागे की संख्या को 300 तक बढ़ा देती है तो सर्वर बहुत जल्द क्रैश हो जाता है। क्या आप कृपया मुझे बताएं कि मॉलोक के डिबगिंग संस्करण का उपयोग करने से कैसे मदद मिल सकती है? धन्यवाद –
'डिबगिंग मॉलोक' के संबंध में: यदि समस्या स्मृति दुर्व्यवहार है, तो डिबगिंग मॉलोक आवंटित स्थान के बारे में अधिक जानकारी रिकॉर्ड करके मदद करेगा, आमतौर पर अधिक स्थान आवंटित करके, इसलिए जब उसके कार्यों को बुलाया जाता है, तो वे विभिन्न प्रकारों को खोज सकते हैं प्रक्रिया में पहले स्मृति दुर्व्यवहार की - क्षति को सीमित करना और आमतौर पर परेशानी को सुलझाना आसान बनाना। उदाहरण के लिए, यदि आप स्मृति के पहले से ही मुक्त खंड को मुक्त करते हैं, तो यह इसकी रिपोर्ट कर सकता है - केवल मुफ़्त मूल्य पर अपना मुकाबला करने और उस जानकारी के साथ काम करने के बजाय जो वास्तव में वहां नहीं है। एक सरल malloc() कार्यान्वयन के लिए के एंड आर देखें। –
'200 धागे के तहत ठीक है; जल्द से जल्द 300 से अधिक दुर्घटनाएं; क्या आपने देखा है कि सर्वर कुछ संसाधन (शायद 200, शायद 256) के एक निश्चित आकार पूल आवंटित करता है और उस संसाधन के थकावट के लिए उचित रूप से जांच नहीं करता है। यह म्यूटेक्स, या सेमफोरस, या कुछ और जो स्मृति स्मृति दुरुपयोग को ट्रिगर कर रहा है का एक सेट हो सकता है। क्या आपके द्वारा लिखा गया सर्वर कोड है? क्या आपको काम पर धागे की संख्या सीमित करना चाहिए? –