2009-07-25 10 views
15

दोस्तों पर स्मृति भ्रष्टाचार का पता लगाना, क्या आप कृपया सी ++ के साथ निर्मित उत्पादन मल्टीथ्रेड सर्वर पर मेमोरी भ्रष्टाचार को ढूंढने और लिनक्स x86_64 के तहत काम करने के लिए एक उपकरण की सिफारिश कर सकते हैं? मुझे वर्तमान में निम्न समस्या का सामना करना पड़ रहा है: हर सर्वर में मेरा सर्वर एक सेगफॉल्ट के साथ दुर्घटनाग्रस्त हो जाता है और कोर डंप से पता चलता है कि त्रुटि malloc/calloc में होती है जो निश्चित रूप से कहीं भी दूषित स्मृति का संकेत है।उत्पादन लिनक्स सर्वर

दरअसल मैंने पहले से ही कुछ भाग्य के बिना कुछ टूल आजमाए हैं।

  • वेलग्रिंड एक महान (मैं भी कहेंगे सबसे अच्छा) उपकरण है, लेकिन यह सर्वर धीमा बहुत ज्यादा यह उत्पादन में व्यर्थ कर रही है: यहाँ मेरा अनुभव अब तक है। मैंने इसे स्टेज सर्वर पर आज़माया और वास्तव में मुझे कुछ स्मृति संबंधी मुद्दों को खोजने में मदद मिली लेकिन उन्हें ठीक करने के बाद भी मुझे उत्पादन सर्वर पर दुर्घटनाएं मिलती हैं। मैंने कई घंटे तक वालग्रींड के तहत अपना मंच सर्वर चलाया लेकिन फिर भी कोई गंभीर त्रुटियां नहीं मिलीं।

  • इलेक्ट्रिकफ़ेंस को वास्तविक स्मृति हॉग कहा जाता है लेकिन मैं इसे ठीक से काम नहीं कर सका। यह लगभग तुरंत यादृच्छिक अजीब स्थानों में मंच सर्वर पर segfaults जहां Valgrind कोई भी मुद्दा नहीं दिखाया। शायद इलेक्ट्रिकफेंस अच्छी तरह से थ्रेडिंग का समर्थन नहीं करता है? .. मुझे नहीं पता।

  • डुमा - इलेक्ट्रिकफ़ेंस के समान कहानी लेकिन इससे भी बदतर। जबकि ईएफ ने पठनीय बैकट्रैस के साथ कोर डंप का उत्पादन किया है, डीयूएमए मुझे केवल "?????" दिखाता है (और हाँ सर्वर निश्चित रूप से ध्वज के साथ बनाया गया है)

  • dmalloc - मैंने मानक मैलोक के बजाय सर्वर का उपयोग करने के लिए कॉन्फ़िगर किया दिनचर्या हालांकि यह कई मिनट के बाद लटकती है। । संलग्न की प्रक्रिया के लिए एक gdb का पता चलता है यह dmalloc :(

मैं धीरे-धीरे पागल हो रही है और बस आगे क्या करना है पता नहीं है में कहीं लटका दिया है मैं निम्नलिखित उपकरणों की कोशिश की जा करने के लिए है: mtrace, mpatrol लेकिन शायद किसी को एक बेहतर विचार है

मैं बहुत इस मुद्दे पर किसी भी मदद की सराहना करेंगे,

अद्यतन:?।। मैं बग का स्रोत खोज करने में कामयाब हालांकि मैं मंच सर्वर पर नहीं मिला उत्पादन एक हेल्ग्रिंड/डीआरडी/tsan का उपयोग कर - कई धागे के बीच एक डाटरस था जिसके परिणामस्वरूप स्मृति भ्रष्ट आयन। कुंजी उचित वाल्ग्रिंड दमन का उपयोग करना था क्योंकि इन उपकरणों ने बहुत अधिक झूठे सकारात्मक दिखाए थे। फिर भी मैं सच में नहीं पता कि यह कैसे किसी भी महत्वपूर्ण मंदी के बिना उत्पादन सर्वर पर खोज की जा सकती है ...

+1

क्या आपने LD_PRELOAD env चर में libefence संकलित या उपयोग किया था? इलेक्ट्रिकफेंस थ्रेड सुरक्षित माना जाता है अगर इसे -DUSE_SEMAPHORE –

+0

के साथ संकलित किया गया है, तो मैं libefense.a नहीं उपयोग कर रहा हूं। और मैंने इसे स्वयं संकलित नहीं किया, मैंने Gentoo पर उभरने का उपयोग किया। क्या आप इस ध्वज के बजाय मैन्युअल रूप से इसे स्थापित करने की अनुशंसा करेंगे? – pachanga

+2

एक चीज जो मदद कर सकती है वह है +/- 200 बाइट्स जहां सेग गलती ने कहा कि डेटा दूषित है। डेटा को देखकर आप एक विचार प्राप्त कर सकते हैं कि स्मृति भ्रष्टाचार का कारण क्या है। – steve

उत्तर

4

दोस्तों, मैं बग का स्रोत ढूंढने में कामयाब रहा। हालांकि मैंने इसे हेल्ग्रिंड/डीआरडी/त्सन का उपयोग करके स्टेज सर्वर पर पाया - कई थ्रेडों के बीच एक डाटरस था जिसके परिणामस्वरूप स्मृति भ्रष्टाचार हुआ। कुंजी को उचित वाल्ग्रिंड दमन का उपयोग करना था क्योंकि इन उपकरणों ने बहुत अधिक झूठे सकारात्मक दिखाए थे। फिर भी मुझे वास्तव में पता नहीं है कि उत्पादन सर्वर पर किसी भी महत्वपूर्ण मंदी के बिना यह कैसे खोजा जा सकता है ...

1

आप आईबीएम को शुद्ध कोशिश कर सकते हैं, लेकिन मुझे डर है कि ओपनसोर्स नहीं है कर रहा हूँ ..

+0

ठीक है अगर कुछ और काम नहीं करता है ... लेकिन मुझे अभी भी विश्वास है कि इसके लिए ओपनसोर्स समाधान होना चाहिए। – pachanga

+0

शुद्ध करने के लिए आवेदन को धीमा कर दें और उत्पादन मशीन पर इसका उपयोग नहीं किया जा सकता है। – steve

7

हाँ, सी/सी ++ स्मृति भ्रष्टाचार की समस्याएं कठिन हैं। मैंने कई बार वाल्ग्रिंड का भी उपयोग किया, कभी-कभी यह समस्या का खुलासा करता है और कभी-कभी नहीं।

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

एक और सलाह पहले ज्ञात स्थिर रिलीज से कोड परिवर्तनों की तुलना करना है। यदि आप किसी प्रकार के स्रोत संस्करण प्रणाली (उदा। Svn) का उपयोग करते हैं तो यह कोई समस्या नहीं है। सभी मेमोरी से संबंधित कार्यों की जांच करें (उदा। Memcpy, memset, sprintf, new, हटाएं/हटाएं [])।

+1

+1 वाल्ग्रिंड हड़ताली वापस अनदेखा करने के लिए +1 – LiraNuna

+0

सभी मेमोरी से संबंधित कार्यों की जांच के लिए - मैं उन्हें सीधे कहीं भी उपयोग नहीं करता हूं, सभी पॉइंटर्स shared_ptrs या weak_ptrs हैं और सभी कंटेनर stl से हैं ... – pachanga

+1

एसटीएल अच्छा है लेकिन एसटीएल के साथ भी स्मृति भ्रष्टाचार की समस्या में भाग ले सकते हैं, उदाहरण के लिए अमान्य इटरेटर का उपयोग क्यों करें। देखें http://www.angelikalanger.com/Conferences/Slides/CppInvalidIterators-DevConnections-2002.pdf – dimba

1

Google परफटोल्स --- जो ओपन सोर्स है --- मदद की हो सकती है, heap checker दस्तावेज़ीकरण देखें।

+0

धन्यवाद, इसे आजमाने के लिए अभी – pachanga

+0

दुर्भाग्यवश हीप चेकर बहुत सीमित है, यह केवल स्मृति लीक का पता लगा सकता है और स्मृति ओवररन्स नहीं कर सकता है। यह नए मिलान को भी नहीं ढूंढ सकता []/हटाएं :( – pachanga

6

जीसीसी 4.1 और -फस्टैक-रक्षक-सभी स्विच के साथ अपने प्रोग्राम को संकलित करें। अगर मेमोरी भ्रष्टाचार स्टैक स्मैशिंग के कारण होता है तो इसे पहचानने में सक्षम होना चाहिए। आपको एसएसपी के कुछ अतिरिक्त पैरामीटर के साथ खेलना पड़ सकता है।

3

क्या आपने -fmudflap को आजमाया है? (उपलब्ध विकल्पों को देखने के लिए कुछ पंक्तियों को स्क्रॉल करें)।

+0

धन्यवाद, मुझे यह लिंक भी मिला है http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging – pachanga

+0

मैं वर्तमान में "त्रुटि: mudflap अज्ञात आकार बाहरी को ट्रैक नहीं कर सकता '__prime_list' "त्रुटियां :(कोई विचार क्यों वे हो सकते हैं? मेरे पास कोड में कहीं भी __prime_list प्रतीक नहीं है ... – pachanga

+0

यह libmudflap पर स्थापित होने पर भरोसा करता है। शायद यह नहीं है? – supercheetah

1

इस एक का प्रयास करें: http://www.hexco.de/rmdebug/ मैं इसे बड़े पैमाने पर इस्तेमाल, इसके प्रदर्शन में एक कम प्रभाव पड़ता है (यह ज्यादातर राम के प्रभावों राशि), लेकिन आबंटन एल्गोरिथ्म एक ही है। यह हमेशा किसी भी आवंटन कीड़े खोजने के लिए पर्याप्त साबित हुआ। जैसे ही बग होता है आपका प्रोग्राम क्रैश हो जाएगा, और इसमें एक विस्तृत लॉग होगा।

+0

धन्यवाद है, मैं ' इसे देखेंगे।मुझे आश्चर्य है कि यह एक सी ++ मल्टीथ्रेडिंग ऐप में ठीक काम करता है ... – pachanga

+0

हां, थ्रेडिंग का कोई प्रभाव नहीं होना चाहिए – daniel

1

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

+0

धन्यवाद, मैंने इसे भी कोशिश की है (MALLOC_CHECK_ = 3), हालांकि, यह मेरी स्मृति का कोई स्रोत नहीं दिखाता भ्रष्टाचार के बाद से (जैसा कि मैंने पहले लिखा था) स्मृति को मटरोक द्वारा मुक्त किया गया था न कि मॉलोक/मुफ्त के अनुचित उपयोग से ... – pachanga

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

  • कोई संबंधित समस्या नहीं^_^