मेमोरी लीक को ठीक करना कितना महत्वपूर्ण है?

19

मैंने Valgring द्वारा पाया कि कुछ GTK + प्रोग्राम मेमोरी को लीक करते हैं। उन लीक को ठीक करना कितना महत्वपूर्ण है? मेरा मतलब है, अक्सर वे कार्यक्रम बहुत अच्छी तरह से काम करते हैं, लेकिन दूसरी ओर, कोई भी निश्चित नहीं हो सकता है अगर कोई लीक कोड के हिस्से को किसी अन्य प्रोग्राम में कॉपी करना चाहता है। और मुझे यकीन नहीं है कि जीटीके + -प्रोग्राम्स का विचार तेजी से काम करना है और इसलिए लीक हैं।

इसलिए यदि मुझे कभी-कभी एक ओपन सोर्स प्रोग्राम में मेमोरी लीक होती है, तो क्या मुझे इसे ठीक करना चाहिए या उदाहरण दक्षता मुद्दों के लिए हैं और इसलिए प्रोग्रामर का मूल विचार कुछ छोटे लीक कोड लिखने का था?

c memory

— जाको सेप्पला
स्रोत

17

मेमोरी लीक हमेशा अवांछनीय होते हैं । वे उन संसाधनों का प्रतिनिधित्व करते हैं जिनका पूरा सिस्टम मेजबान कार्यक्रम सहित उपयोग नहीं कर सकता, जब तक कि कार्यक्रम समाप्त न हो जाए।

— recursion.ninja

पर्याप्त उपकरण / पुस्तकालय हैं जो ट्रेसिंग मेमोरी लीक से निपटते हैं। यह प्रयास के लायक है, क्योंकि आपके पक्ष में एपीआई का उपयोग गलत हो सकता है।

— जोप एगेगन

1

एक साइड नोट के रूप में - वेलग्रिंड के महान लेकिन कुछ गलत सकारात्मक रिपोर्ट कर सकते हैं (मैंने उन्हें गोब्जेक्ट में देखा है)।

— मैकीज पाइचोटका

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

— imallett

1

"हमेशा ऐसा कोड करें जैसे कि जो व्यक्ति आपका कोड बनाए रखता है वह एक हिंसक मनोरोगी है जो जानता है कि आप कहां रहते हैं।"

— जेसी सी। स्लीकर

6

मेमोरी लीक को ठीक करना कितना महत्वपूर्ण है यह समस्या की गंभीरता पर निर्भर करता है और आपको जो करना है वह महत्वपूर्ण है। मेरा अनुभव है कि अधिकांश अनुप्रयोगों के लिए छोटी मेमोरी लीक अधिक सौम्य होती है। एक डेस्कटॉप ऐप सत्र का जीवनकाल आमतौर पर एक छोटे मेमोरी लीक से किसी भी गिरावट को देखने के लिए पर्याप्त नहीं है।

यदि आप एक सर्वर लिख रहे हैं जो 24/7 चलता है, तो छोटी मेमोरी लीक समय के साथ जुड़ सकती है और एक बड़ी समस्या बन सकती है। लेकिन यही कारण है कि कई कंपनियां अपने सर्वर को दैनिक या साप्ताहिक पुनः आरंभ करने के लिए शेड्यूल करती हैं। मेमोरी लीक्स को खोजने का प्रयास अक्सर प्राप्त किए जाने के सापेक्ष अत्यधिक होता है, इसलिए नियमित आधार पर सर्वर को पुनरारंभ करना और अधिक महत्वपूर्ण चीजों पर आगे बढ़ना आसान होता है।

— महीन चिकना ऊन
स्रोत

2

मैंने कभी ऐसी कंपनी में काम नहीं किया है जो अपने सर्वर को साप्ताहिक रूप से फिर से शुरू करती है ... यहां तक कि दैनिक भी। मैं सहमत हूं कि रिसाव को ठीक करने के लिए लागत तय हो सकती है, लेकिन इसे ठीक करने के लिए उच्च हो सकता है लेकिन यह मानसिकता अच्छी नहीं है IMO

— Rémi

@ Rémi अधिकांश, यदि सभी नहीं, तो MMO खेल सर्वर आमतौर पर साप्ताहिक आधार पर करते हैं।

— सोजेरड

35

कम चलने वाले कार्यक्रमों के लिए मेमोरी लीक उतना महत्वपूर्ण नहीं है; ओएस समाप्ति पर सब कुछ पुनः प्राप्त करेगा, लेकिन वे अन्य संसाधनों को जारी नहीं कर सकते हैं।

हालांकि कम चलना सापेक्ष है, एक रिसाव कुछ ही घंटों में नियंत्रण से बाहर हो सकता है या बिना किसी कारण के हफ्तों तक ढेर हो सकता है।

मेरी सलाह है कि ट्रैकर में एक प्रस्तावित फिक्स के साथ एक बग दर्ज करें, अगर लीड परवाह करता है तो वह इसे ठीक कर देगा।

रिसाव का प्रकार भी महत्वपूर्ण है। यह संभव है कि जो लीक लीक हो, वह एकतरफा आवंटन हो, जहां देव जानबूझकर सफाई के लिए ओएस पर निर्भर थे। ये वैलग्राइंड पर एक झूठी सकारात्मक देगा।

— शाफ़्ट सनकी
स्रोत

4

मैं ज्यादातर सहमत हूं। हालांकि मेरा सुझाव है कि आप स्मृति रिसाव के महत्व पर जोर दें। मेमोरी लीक को हल्के में नहीं लेना है और आपके आवेदन के कुछ दिलचस्प "सुविधाओं" का कारण बन सकता है।

— व्लादिमीर कोकजेन्सिक

@VladimirKocjancic: "फ़ीचर" के लिए +1

— एमिलियो गरवाग्लिया

1

मैं केवल यह बताना चाहता हूं कि एक कंप्यूटर कई मिलियन बार एक मिलियन प्रसंस्करण करने में सक्षम है, जो बहुत जल्दी होता है। कभी मत भूलना। इसलिए यदि आप इसे ध्यान में रखते हैं तो मैं इस उत्तर से सहमत हूं, क्योंकि यह वास्तव में कार्यक्रम पर निर्भर करता है। मानव हस्तक्षेप के बिना चलने के लिए एक अंतर्निहित प्रणाली के लिए, मेमोरी लीक घातक हैं। "Grep" कार्यान्वयन के लिए आप शायद कम देखभाल नहीं कर सकते।

— डंक

2

@ डंक: यह निर्भर करता है: यदि आप grepएक बहुत बड़ी फ़ाइल के माध्यम से और आपका प्रोग्राम प्रत्येक इनपुट लाइन के लिए कुछ बाइट्स लीक करता है, तो आप मेमोरी से बाहर चला सकते हैं।

— जियोर्जियो

0

इस एक विषय पर मेरी स्वाभाविक रूप से हठधर्मिता में, किसी भी पुस्तकालय में कम से कम भौतिक लीक के लिए कोई बहाना नहीं है जिसका उद्देश्य व्यापक रूप से लागू होना है। इसलिए मैं GTK + डेवलपर्स को तब तक बग करना चाहूंगा जब तक वे इसे स्वयं ठीक नहीं कर लेते।

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

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

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

तार्किक लीक (अधिक जटिल प्रकार जो कचरा संग्रह से भी रक्षा नहीं कर सकता है) एक अधिक जटिल मुद्दा है, और वहां मुझे अल्पकालिक कार्यक्रमों के लिए तार्किक लीक होने के लिए कुछ औचित्य मिल सकता है, क्योंकि वे उस सभी मेमोरी को शुद्ध करते हैं जो उन्होंने आवंटित की थी शटडाउन के बाद से इसे तार्किक लीक से बचने के लिए संसाधन प्रबंधन के बारे में बहुत अधिक विचार करने की आवश्यकता है (जीसी है जो भाषाओं में अधिक है)। लेकिन मुझे शारीरिक लीक से बचने के लिए कोई उचित बहाना नहीं मिल रहा है, यह देखते हुए कि वे सबसे आलसी संदर्भों में भी कैसे बचते हैं।

वैसे भी, कम से कम मैं वेलग्रिंड में लीक को फ़िल्टर कर दूंगा ताकि वे कम से कम आपकी टीम की अपनी क्षमता के साथ खिलवाड़ न करें।

1

मुझे आश्चर्य है कि अगर लीक का "बोट कोडिंग" से कोई लेना-देना है?

0

एफडब्ल्यूआईडब्ल्यू, अगर किसी उपयोगकर्ता ने एक एप्लिकेशन में एक रिसाव की सूचना दी, जिस पर मैं काम करता हूं, तो मैं इसे ठीक करने के लिए इच्छुक हूं (विशेषकर यदि वे बग रिपोर्ट में फिक्स के लिए कोड शामिल करते हैं!)। अगर रिसाव छोटा था और अन्य मुद्दे अधिक दबाव वाले थे (तो, एक दुर्घटनाग्रस्त बग जो अक्सर हुआ)। लेकिन मैं निश्चित रूप से इसकी सराहना करूंगा और अंततः इसे ठीक करने के लिए काम करूंगा। आपको उन्हें जरूर बताना चाहिए। वे या तो इसकी सराहना करेंगे और इसे (सबसे अधिक संभावना) ठीक करने के लिए काम करेंगे, या वे परवाह नहीं करेंगे और यह सब आपके पास कुछ समय होगा।

— user1118321
स्रोत