c++ - मेमोरी लीक कभी ठीक है?




memory-leaks (20)

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

इसके साथ ही, ऐसे समय भी होंगे जब आपके पास वास्तविक मेमोरी लीक होंगी जिन्हें खोजने में बहुत मुश्किल होती है या उन्हें ठीक करना मुश्किल होता है। तो अब प्रश्न बन गया है कि उन्हें कोड में छोड़ना ठीक है?

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

क्या आपके सी या सी ++ एप्लिकेशन में मेमोरी लीक होने के लिए कभी स्वीकार्य है?

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

क्या होगा अगर किसी तीसरे पक्ष की लाइब्रेरी ने आपको इस स्थिति को मजबूर कर दिया? उस तीसरे पक्ष की लाइब्रेरी का उपयोग करने से इंकार कर देगा इससे कोई फर्क नहीं पड़ता कि यह अन्यथा कितना अच्छा हो सकता है?

मुझे केवल एक व्यावहारिक नुकसान दिखाई देता है, और यह है कि ये सौम्य रिसाव स्मृति रिसाव पहचान उपकरण के साथ झूठी सकारात्मक के रूप में दिखाई देंगे।


आवेदन चलाने के बाद ओएस साफ होने के साथ अवधारणात्मक रूप से कुछ भी गलत नहीं है।

यह वास्तव में आवेदन पर निर्भर करता है और यह कैसे चलाया जाएगा। सप्ताह में चलाने के लिए आवश्यक एप्लिकेशन में लगातार होने वाली लीक की देखभाल की जानी चाहिए, लेकिन एक छोटा सा टूल जो बिना किसी स्मृति की आवश्यकता के परिणाम की गणना करता है, एक समस्या नहीं होनी चाहिए।

एक कारण है कि कई स्क्रिप्टिंग भाषा कचरा नहीं है चक्रीय संदर्भों को इकट्ठा करते हैं ... उनके उपयोग पैटर्न के लिए, यह एक वास्तविक समस्या नहीं है और इस तरह बर्बाद स्मृति के रूप में संसाधनों की बर्बादी होगी।


जबकि अधिकांश उत्तर वास्तविक स्मृति रिसाव पर ध्यान केंद्रित करते हैं (जो कि ठीक नहीं हैं, क्योंकि वे मैला कोडिंग का संकेत हैं), प्रश्न का यह हिस्सा मेरे लिए और अधिक दिलचस्प प्रतीत होता है:

क्या होगा यदि आप कुछ मेमोरी आवंटित करते हैं और अपने आवेदन में कोड की आखिरी पंक्ति तक इसका उपयोग करते हैं (उदाहरण के लिए, एक वैश्विक वस्तु का deconstructor)? जब तक स्मृति की खपत समय के साथ बढ़ती नहीं है, तब तक ओएस पर भरोसा करना ठीक है जब आपका एप्लिकेशन समाप्त हो जाता है (विंडोज़, मैक और लिनक्स पर)? अगर आप ओएस द्वारा मुक्त किए जाने तक स्मृति का लगातार इस्तेमाल किया जा रहा था, तो क्या आप इसे वास्तविक स्मृति रिसाव पर भी विचार करेंगे।

यदि संबंधित मेमोरी का उपयोग किया जाता है, तो प्रोग्राम समाप्त होने से पहले आप इसे मुक्त नहीं कर सकते हैं। चाहे कार्यक्रम से बाहर निकलें या ओएस द्वारा किया जाता है, इससे कोई फर्क नहीं पड़ता। जब तक यह दस्तावेज किया जाता है, तो परिवर्तन वास्तविक स्मृति रिसाव को पेश नहीं करता है, और जब तक चित्र में कोई सी ++ विनाशक या सी क्लीनअप फ़ंक्शन शामिल नहीं होता है। एक लीक वाली FILE ऑब्जेक्ट के माध्यम से एक बंद-बंद फ़ाइल प्रकट नहीं की जा सकती है, लेकिन एक गायब fclose () भी बफर को फ़्लश नहीं कर सकता है।

तो, मूल मामले पर, यह आईएमएचओ पूरी तरह से ठीक है, इतना है कि सबसे शक्तिशाली रिसाव डिटेक्टरों में से एक वालग्रिंड, अनुरोध किए जाने पर ही ऐसे लीक का इलाज करेगा। वालग्रिंड पर, जब आप इसे पहले बिना मुक्त किए पॉइंटर को ओवरराइट करते हैं, तो इसे स्मृति रिसाव के रूप में माना जाता है, क्योंकि यह फिर से होने की संभावना है और ढेर को अंतहीन रूप से विकसित करने की संभावना है।

फिर, nfreed मेमोरी ब्लॉक नहीं हैं जो अभी भी पहुंच योग्य हैं। कोई भी उन सभी को बाहर निकलने पर मुक्त कर सकता है, लेकिन यह सिर्फ समय में बर्बाद है। मुद्दा यह है कि अगर उन्हें पहले मुक्त किया जा सकता है। किसी भी मामले में स्मृति खपत को कम करना उपयोगी है।


नहीं।

पेशेवरों के रूप में, सवाल यह है कि हमें खुद से नहीं पूछना चाहिए, "क्या यह कभी करना ठीक है?" बल्कि "क्या ऐसा करने का कोई अच्छा कारण है?" और "उस स्मृति रिसाव को शिकार करना एक दर्द है" एक अच्छा कारण नहीं है।

मैं चीजों को सरल रखना पसंद करता हूं। और सरल नियम यह है कि मेरे कार्यक्रम में कोई स्मृति रिसाव नहीं होना चाहिए।

इससे मेरा जीवन भी सरल हो जाता है। अगर मैं मेमोरी रिसाव का पता लगाता हूं, तो यह निर्धारित करने के लिए कि क्या यह एक "स्वीकार्य" स्मृति रिसाव है, मैं कुछ विस्तृत निर्णय वृक्ष संरचना के माध्यम से इसे चलाने के बजाय इसे खत्म कर देता हूं।

यह संकलक चेतावनियों के समान है - क्या चेतावनी मेरे विशेष आवेदन के लिए घातक होगी? शायद नहीं।

लेकिन यह अंततः पेशेवर अनुशासन का मामला है। टोलरेटिंग कंपाइलर चेतावनियां और मेमोरी लीक को सहन करना एक बुरी आदत है जो आखिरकार मुझे पीछे की ओर काट देगी।

चीजों को चरम पर ले जाने के लिए, क्या कभी एक सर्जन के लिए एक रोगी के अंदर ऑपरेटिंग उपकरण का कुछ टुकड़ा छोड़ना स्वीकार्य होगा?

यद्यपि यह संभव है कि एक परिस्थिति उत्पन्न हो सकती है जहां उपकरण के उस टुकड़े को हटाने की लागत / जोखिम इसे छोड़ने की लागत / जोखिम से अधिक है, और ऐसी परिस्थितियां हो सकती हैं जहां यह हानिकारक हो, अगर मैंने यह प्रश्न SurgeonOverflow.com पर पोस्ट किया और "नहीं" के अलावा कोई जवाब देखा, यह चिकित्सा पेशे में अपने आत्मविश्वास को गंभीरता से कमजोर कर देगा।

-

यदि किसी तीसरे पक्ष की लाइब्रेरी ने मुझे इस स्थिति को मजबूर कर दिया है, तो इससे मुझे लाइब्रेरी की समग्र गुणवत्ता पर गंभीरता से संदेह होगा। ऐसा लगता है जैसे मैंने एक कार चलाया और कपड़ों में से एक में दो ढीले वाशर और पागल पाया - यह अपने आप में एक बड़ा सौदा नहीं हो सकता है, लेकिन यह गुणवत्ता के प्रति प्रतिबद्धता की कमी दर्शाता है, इसलिए मैं विकल्पों पर विचार करता हूं।


मुझे यकीन है कि कोई हां कहने के कारण से आ सकता है, लेकिन यह मैं नहीं होगा। नहीं कहने के बजाय, मैं यह कहने जा रहा हूं कि यह एक हां / नहीं सवाल होना चाहिए। मेमोरी लीक को प्रबंधित करने या रखने के तरीके हैं, और कई प्रणालियों में उन्हें हैं।

ऐसे उपकरणों पर नासा सिस्टम हैं जो पृथ्वी को छोड़ देते हैं जो इसके लिए योजना बनाते हैं। सिस्टम स्वचालित रूप से हर बार स्वचालित रूप से रीबूट हो जाएंगे ताकि स्मृति रिसाव पूरे ऑपरेशन के लिए घातक न हो जाए। बस रोकथाम का एक उदाहरण।


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

यदि यह एक तृतीय पक्ष पुस्तकालय है तो आप फंस सकते हैं। लेकिन निश्चित रूप से दस्तावेज है कि यह रिसाव होता है।

लेकिन मूल रूप से यदि स्मृति रिसाव एक ज्ञात मात्रा 512 केबी बफर या कुछ है तो यह एक गैर मुद्दा है। यदि मेमोरी रिसाव हर बार जब आप लाइब्रेरी कॉल करते हैं, तो आपकी याददाश्त 512 केबी तक बढ़ जाती है और मुक्त नहीं होती है, तो आपको कोई समस्या हो सकती है। यदि आप इसे दस्तावेज करते हैं और कॉल को निष्पादित करने की संख्या को नियंत्रित करते हैं तो यह प्रबंधनीय हो सकता है। लेकिन फिर आपको वास्तव में दस्तावेज़ीकरण की आवश्यकता है क्योंकि 512 अधिक नहीं है, जबकि 512 से अधिक कॉल एक लाख है।

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


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

क्यूं कर? स्मृति को मुक्त करने के लिए स्मृति को छूने की आवश्यकता होती है। यहां तक ​​कि यदि आपके सिस्टम का मॉलोक कार्यान्वयन आवंटित स्मृति ब्लॉक के आस-पास मेटाडेटा को संग्रहीत नहीं करता है, तो संभवतः आप उन सभी पॉइंटर्स को ढूंढने के लिए रिकर्सिव स्ट्रक्चर चलने जा रहे हैं जिन्हें आपको खाली करने की आवश्यकता है।

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

यह सिर्फ सैद्धांतिक नहीं है। जब भी मैं खुद को बहुत से ऐप्स लोड कर लेता हूं और डिस्क थ्रैशिंग शुरू होती है, तो मैं "बाहर निकलने" पर क्लिक करने पर भी विचार नहीं करता हूं। मैं जितनी जल्दी हो सके टर्मिनल पर जा सकता हूं और killall -9 टाइप कर सकता हूं ... क्योंकि मुझे पता है कि "बाहर निकलना" सिर्फ इसे और खराब कर देगा।


मैं इसे स्मृति रिसाव नहीं मानता जब तक कि "उपयोग" की स्मृति की मात्रा बढ़ती रहती है। कुछ अपरिवर्तित स्मृति होने के बावजूद, आदर्श नहीं होने पर, एक बड़ी समस्या नहीं है जब तक कि आवश्यक स्मृति की मात्रा बढ़ती रहती है।


मैं वास्तव में एक स्मृति रिसाव क्या है की इतनी गलत परिभाषाओं को देखकर हैरान हूं। एक ठोस परिभाषा के बिना, यह एक बुरी बात है या नहीं, इस पर एक चर्चा कहीं भी नहीं जाएगी।

जैसा कि कुछ टिप्पणीकारों ने सही ढंग से इंगित किया है, एक स्मृति रिसाव केवल तब होता है जब किसी प्रक्रिया द्वारा आवंटित स्मृति इस सीमा तक समाप्त हो जाती है कि प्रक्रिया अब संदर्भित करने या हटाने में सक्षम नहीं है।

एक प्रक्रिया जो अधिक से अधिक स्मृति को पकड़ रही है वह जरूरी नहीं है। जब तक वह उस स्मृति को संदर्भित और अस्वीकार करने में सक्षम है, तब यह प्रक्रिया के स्पष्ट नियंत्रण में रहता है और लीक नहीं हुआ है। प्रक्रिया को बुरी तरह से डिजाइन किया जा सकता है, खासकर उस प्रणाली के संदर्भ में जहां स्मृति सीमित है, लेकिन यह रिसाव के समान नहीं है। Conversely, losing scope of, say, a 32 byte buffer is still a leak, even though the amount of memory leaked is small. If you think this is insignificant, wait until someone wraps an algorithm around your library call and calls it 10,000 times.

I see no reason whatsoever to allow leaks in your own code, however small. Modern programming languages such as C and C++ go to great lengths to help programmers prevent such leaks and there is rarely a good argument not to adopt good programming techniques - especially when coupled with specific language facilities - to prevent leaks.

As regards existing or third party code, where your control over quality or ability to make a change may be highly limited, depending on the severity of the leak, you may be forced to accept or take mitigating action such as restarting your process regularly to reduce the effect of the leak.

It may not be possible to change or replace the existing (leaking) code, and therefore you may be bound to accept it. However, this is not the same as declaring that it's OK.


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

वास्तव में, बाहर निकलने से पहले कॉल करने के लिए कॉल करने की आवश्यकता नहीं है () या बाहर निकलने से पहले सही हटाएं। जब प्रक्रिया निकलती है, तो इसकी सभी मेमोरी ओएस द्वारा पुनः प्राप्त की जाती है (यह निश्चित रूप से पॉज़िक्स के साथ मामला है। अन्य ओएस पर - विशेष रूप से एम्बेडेड वाले - वाईएमएमवी)।

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


यह इतना डोमेन-विशिष्ट है कि इसका उत्तर देने योग्य नहीं है। अपने सनकी सिर का प्रयोग करें।

  • अंतरिक्ष शटल ऑपरेटिंग सिस्टम: नहीं, कोई मेमोरी लीक की अनुमति नहीं है
  • तेजी से विकास प्रमाण-अवधारणा कोड: उन सभी स्मृति रिसाव को ठीक करना समय की बर्बादी है।

और मध्यवर्ती स्थितियों का एक स्पेक्ट्रम है।

सभी को ठीक करने के लिए उत्पाद रिलीज में देरी की अवसर लागत ($$$) लेकिन सबसे खराब मेमोरी लीक आमतौर पर "मैला या गैर-व्यावसायिक" होने की भावनाओं को बौद्ध करती है। आपका मालिक आपको पैसे कमाने के लिए भुगतान करता है, न कि गर्म, अस्पष्ट भावनाएं प्राप्त करने के लिए।


यहां तक ​​कि यदि आप सुनिश्चित हैं कि आपकी 'ज्ञात' मेमोरी रिसाव खतरे का कारण नहीं बनती है, तो ऐसा न करें। सबसे अच्छा, यह आपके लिए एक अलग समय और स्थान पर एक समान और शायद अधिक महत्वपूर्ण गलती करने का एक तरीका देगा।

मेरे लिए, यह पूछना प्रश्न पूछने जैसा है "क्या मैं सुबह 3 बजे लाल बत्ती तोड़ सकता हूं जब कोई भी आसपास नहीं है?"। निश्चित रूप से, यह उस समय किसी भी परेशानी का कारण नहीं बन सकता है, लेकिन यह आपके लिए घंटों में ऐसा करने के लिए एक लीवर प्रदान करेगा!


As a general rule, if you've got memory leaks that you feel you can't avoid, then you need to think harder about object ownership.

But to your question, my answer in a nutshell is In production code, yes. During development, no . This might seem backwards, but here's my reasoning:

In the situation you describe, where the memory is held until the end of the program, it's perfectly okay to not release it. Once your process exits, the OS will clean up anyway. In fact, it might make the user's experience better: In a game I've worked on, the programmers thought it would be cleaner to free all the memory before exiting, causing the shutdown of the program to take up to half a minute! A quick change that just called exit() instead made the process disappear immediately, and put the user back to the desktop where he wanted to be.

However, you're right about the debugging tools: They'll throw a fit, and all the false positives might make finding your real memory leaks a pain. And because of that, always write debugging code that frees the memory, and disable it when you ship.


Generally a memory leak in a stand alone application is not fatal, as it gets cleaned up when the program exits.

What do you do for Server programs that are designed so they don't exit?

If you are the kind of programmer that does not design and implement code where the resources are allocated and released correctly, then I don't want anything to do with you or your code. If you don't care to clean up your leaked memory, what about your locks? Do you leave them hanging out there too? Do you leave little turds of temporary files laying around in various directories?

Leak that memory and let the program clean it up? No. Absolutely not. It's a bad habit, that leads to bugs, bugs, and more bugs.

Clean up after yourself. Yo momma don't work here no more.


I agree with vfilby – it depends. In Windows, we treat memory leaks as relatively serous bugs. But, it very much depends on the component.

For example, memory leaks are not very serious for components that run rarely, and for limited periods of time. These components run, do theire work, then exit. When they exit all their memory is freed implicitly.

However, memory leaks in services or other long run components (like the shell) are very serious. The reason is that these bugs 'steal' memory over time. The only way to recover this is to restart the components. Most people don't know how to restart a service or the shell – so if their system performance suffers, they just reboot.

So, if you have a leak – evaluate its impact two ways

  1. To your software and your user's experience.
  2. To the system (and the user) in terms of being frugal with system resources.
  3. Impact of the fix on maintenance and reliability.
  4. Likelihood of causing a regression somewhere else.

Foredecker


I see the same problem as all scenario questions like this: What happens when the program changes, and suddenly that little memory leak is being called ten million times and the end of your program is in a different place so it does matter? If it's in a library then log a bug with the library maintainers, don't put a leak into your own code.


I'll answer no.

In theory, the operating system will clean up after you if you leave a mess (now that's just rude, but since computers don't have feelings it might be acceptable). But you can't anticipate every possible situation that might occur when your program is run. Therefore (unless you are able to conduct a formal proof of some behaviour), creating memory leaks is just irresponsible and sloppy from a professional point of view.

If a third-party component leaks memory, this is a very strong argument against using it, not only because of the imminent effect but also because it shows that the programmers work sloppily and that this might also impact other metrics. Now, when considering legacy systems this is difficult (consider web browsing components: to my knowledge, they all leak memory) but it should be the norm.


Its really not a leak if its intentional and its not a problem unless its a significant amount of memory, or could grow to be a significant amount of memory. Its fairly common to not cleanup global allocations during the lifetime of a program. If the leak is in a server or long running app, grows over time, then its a problem.


This was already discussed ad nauseam . Bottom line is that a memory leak is a bug and must be fixed. If a third party library leaks memory, it makes one wonder what else is wrong with it, no? If you were building a car, would you use an engine that is occasionally leaking oil? After all, somebody else made the engine, so it's not your fault and you can't fix it, right?


आइए पहले हमारी परिभाषाओं को सही बनाएं। एक स्मृति रिसाव तब होती है जब स्मृति गतिशील रूप से आवंटित की जाती है, उदाहरण के लिए malloc() , और स्मृति के सभी संदर्भ इसी प्रकार के बिना खो जाते हैं। एक बनाने का एक आसान तरीका इस तरह है:

#define BLK ((size_t)1024)
while(1){
    void * vp = malloc(BLK);
}

ध्यान दें कि हर बार (1) लूप के आसपास, 1024 (+ ओवरहेड) बाइट आवंटित किए जाते हैं, और नया पता vp को सौंपा गया है; पिछले malloc'ed ब्लॉक के लिए कोई शेष सूचक नहीं है। इस कार्यक्रम को तब तक चलाने की गारंटी दी जाती है जब तक ढेर खत्म नहीं हो जाता है, और किसी भी मॉलोकेड मेमोरी को पुनर्प्राप्त करने का कोई तरीका नहीं है। मेमोरी ढेर से "लीकिंग" है, फिर कभी नहीं देखा जा सकता है।

आप क्या वर्णन कर रहे हैं, हालांकि, ध्वनि की तरह

int main(){
    void * vp = malloc(LOTS);
    // Go do something useful
    return 0;
}

आप स्मृति आवंटित करते हैं, प्रोग्राम समाप्त होने तक इसके साथ काम करते हैं। यह एक स्मृति रिसाव नहीं है; यह प्रोग्राम को खराब नहीं करता है, और जब प्रोग्राम समाप्त हो जाता है तो सभी मेमोरी स्वचालित रूप से खराब हो जाएंगी।

आम तौर पर, आपको स्मृति रिसाव से बचना चाहिए। सबसे पहले, क्योंकि आप से ऊपर की ऊंचाई और हैंगर पर वापस ईंधन, स्मृति जो लीक हो गई है और उसे पुनर्प्राप्त नहीं किया जा सकता है; दूसरा, शुरुआत में मेमोरी लीक को खोजने के बाद शुरुआत में, कोड को सही ढंग से कोड करना बहुत आसान है।







memory-leaks