क्या मेमोरी लीक्स कभी ठीक होते हैं? [बन्द है]


231

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

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

क्या होगा यदि एक तीसरे पक्ष के पुस्तकालय ने इस स्थिति को आप पर मजबूर किया? उस तीसरे पक्ष के पुस्तकालय का उपयोग करने से इंकार कर देंगे चाहे वह कितना भी महान क्यों न हो?

मुझे केवल एक व्यावहारिक नुकसान दिखाई देता है, और वह यह है कि ये सौम्य लीक मेमोरी लीक डिटेक्शन टूल के साथ गलत सकारात्मकता दिखाएंगे।


50
यदि मेमोरी की खपत समय के साथ नहीं बढ़ती है, तो यह रिसाव नहीं है।
mpez0

4
अधिकांश अनुप्रयोगों (सभी .NET प्रोग्रामों सहित) में कम से कम कुछ बफ़र्स होते हैं जिन्हें एक बार आवंटित किया जाता है और कभी भी स्पष्ट रूप से मुक्त नहीं किया जाता है, इसलिए mpez0 की परिभाषा अधिक उपयोगी है।
बेन वोइग्ट

2
हां, अगर आपके पास अनंत स्मृति है।
उपयोगकर्ता

एक "सौम्य" लीक (अगर ऐसी कोई बात है) एक झूठी सकारात्मक नहीं है - यह एक लीक है जिसे बहुत सही ढंग से पता चला था। लीक का पता लगाना, यहां तक ​​कि लीक के लिए भी आप व्यक्तिगत रूप से फिक्सिंग की तरह महसूस नहीं करते हैं, मौजूदा के लिए एक लीक डिटेक्टर का पूरा कारण है।
cHao

1
@ mpez0 "यदि मेमोरी की खपत समय के साथ नहीं बढ़ती है, तो यह रिसाव नहीं है"? यह स्मृति रिसाव की परिभाषा नहीं है। एक रिसाव स्मृति है जो लीक हो गई है, जिसका अर्थ है कि इसे मुक्त नहीं किया गया था और आपके पास अब इसका कोई संदर्भ नहीं है, इसलिए आपके लिए इसे फिर से मुक्त करना असंभव है। यह बढ़ता है या नहीं यह अप्रासंगिक है।
मेक्की

जवाबों:


329

नहीं।

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

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

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

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

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

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

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

-

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


57
एक ही समय में सच और सच नहीं। परम हम में से अधिकांश मजदूरी दास हैं और शिल्प कौशल की किसी भी इच्छा को व्यवसाय की आवश्यकताओं के लिए पीछे की सीट लेनी चाहिए। यदि उस 3 पार्टी लाइब्रेरी में एक रिसाव है और 2 सप्ताह के काम को बचाता है, तो इसका उपयोग करने के लिए एक व्यावसायिक मामला हो सकता है, आदि ...
Cervo

3
मैं वैसे भी पुस्तकालय का उपयोग करूंगा, अगर यह ऐसी चीज है जिसकी मुझे आवश्यकता है और कोई अच्छा विकल्प नहीं था, लेकिन मैं अनुरक्षकों के साथ एक बग में प्रवेश करूंगा।
क्लोच

7
हालांकि मैं व्यक्तिगत रूप से एक ही जवाब के साथ जाऊंगा, ऐसे कार्यक्रम हैं जो शायद ही स्मृति को बिल्कुल मुफ्त करते हैं। इसका कारण यह है कि वे एक) OSes पर चलने के लिए हैं जो मुफ्त मेमोरी और b) बहुत लंबे समय तक नहीं चलने के लिए डिज़ाइन किया गया है। दुर्लभ वास्तव में एक कार्यक्रम के लिए विवश करता है, लेकिन मैं इसे पूरी तरह से मान्य मानता हूं।

2
शुरुआती जाँच के कुछ कारणों को जोड़ने के लिए: जब आपके डिबगिंग टूल "सौम्य" लीक से भर गए हैं, तो आप "वास्तविक" को कैसे खोजने जा रहे हैं? यदि आप एक बैच सुविधा जोड़ते हैं, और अचानक आपका 1K / घंटा रिसाव 1K / सेकंड हो जाता है?
पेट्रिएन डे

5
हम्म "लीक मेमोरी" नहीं "सही" है?
जॉनएमसीजी

80

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


12
तकनीकी रूप से, एक रिसाव स्मृति है जिसे आवंटित किया जाता है और इसके सभी संदर्भ खो जाते हैं। अंत में मेमोरी डील न करना केवल आलसी है।
मार्टिन यॉर्क

17
यदि आपके पास 4 जीबी की 1-बार मेमोरी लीक है, तो यह समस्या है।
जॉन डिब्लिंग

21
इससे कोई फर्क नहीं पड़ता कि यह बढ़ रहा है या नहीं। यदि आपने इसे आवंटित किया है तो अन्य प्रोग्राम मेमोरी का उपयोग नहीं कर सकते हैं।
छिपकली

8
> यदि आपने इसे आवंटित किया है तो अन्य प्रोग्राम मेमोरी का उपयोग नहीं कर सकते हैं। खैर, ओएस हमेशा आपकी मेमोरी को डिस्क पर स्वैप कर सकता है, और अन्य अनुप्रयोगों को उस रैम का उपयोग करने की अनुमति देता है जिसका आप फायदा नहीं उठा रहे थे।
मैक्स लाइब्बर्ट

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

79

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

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

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

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

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

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

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


अब इस आवंटन में से कुछ दर्जन पर विचार करें। अब "मुख्य" शरीर को दिनचर्या में स्थानांतरित करने पर विचार करें जिसे कई बार कहा जाता है। का आनंद लें। - मैं इस भावना से सहमत हूं कि यह इस परिदृश्य में इतनी बड़ी समस्या है, लेकिन परिदृश्य बदलते हैं। जैसा कि वे कहते हैं, हमेशा कोड लिखें जैसे कि यह बनाए रखने के लिए आदमी जानता है कि आप कहां रहते हैं।
पेटेरचेन

2
खैर, मुद्दा यह है कि जब तक मैक्लोड और प्रोग्राम को कॉल नहीं किया जाता है तब तक मेमोरी को _exit () "लीक" नहीं किया जाता है।
चार्ली मार्टिन

1
यह एक मेमोरी लीक है और यह आपके प्रोग्राम को ख़राब कर सकता है। भविष्य के आवंटन इस प्रॉसेस से विफल हो सकते हैं क्योंकि मुझे यकीन है कि आप जाँच कर रहे हैं कि मॉलॉक हर जगह नॉन नील लौटा है। स्मृति का उपयोग करके, जैसे कि एक अंतर्निहित स्थिति में जहां याद रखना दुर्लभ है, यह जीवन और मृत्यु के बीच का अंतर हो सकता है।
माइक जे

10
माइक, यह सिर्फ सच नहीं है। एक आज्ञाकारी सी वातावरण में, मुख्य समापन सभी प्रक्रिया संसाधनों को मुक्त करता है। आपके जैसे परिवेश में, आप उस स्थिति को देख सकते हैं, लेकिन आपके पास मुख्य नहीं होगा। अब, मैं अनुदान देता हूं कि त्रुटिपूर्ण एम्बेडेड वातावरण हो सकते हैं जिसके लिए यह सच नहीं होगा, लेकिन फिर मैंने त्रुटिपूर्ण वातावरण देखा है जो कि + = सही ढंग से भी सामना नहीं कर सका।
चार्ली मार्टिन

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

39

सिद्धांत रूप में, व्यवहार में यह निर्भर करता है

यह वास्तव में इस बात पर निर्भर करता है कि कार्यक्रम कितना डेटा पर काम कर रहा है, कितनी बार कार्यक्रम चलाया जाता है और यह लगातार चल रहा है या नहीं।

अगर मेरे पास एक त्वरित कार्यक्रम है जो डेटा की एक छोटी मात्रा को पढ़ता है, तो गणना करता है और बाहर निकलता है, एक छोटी मेमोरी लीक पर कभी ध्यान नहीं दिया जाएगा। क्योंकि प्रोग्राम बहुत लंबे समय तक नहीं चल रहा है और केवल थोड़ी मात्रा में मेमोरी का उपयोग करता है, प्रोग्राम के मौजूद होने पर रिसाव छोटा और मुक्त हो जाएगा।

दूसरी ओर अगर मेरे पास एक कार्यक्रम है जो लाखों रिकॉर्डों को संसाधित करता है और लंबे समय तक चलता है, तो एक छोटी मेमोरी लीक मशीन को पर्याप्त समय तक नीचे ला सकती है।

तीसरे पक्ष के पुस्तकालयों के लिए जिनके पास लीक है, यदि वे समस्या का कारण बनते हैं या तो पुस्तकालय को ठीक करें या एक बेहतर विकल्प खोजें। यदि यह समस्या पैदा नहीं करता है, तो क्या यह वास्तव में मायने रखता है?


मुझे नहीं पता कि आपने मेरा पूरा प्रश्न पढ़ा या नहीं। मैं कह रहा हूं कि मेमोरी का उपयोग एप्लिकेशन के बहुत अंत तक किया जाता है। यह समय के साथ नहीं बढ़ता। केवल कोई नहीं यह नहीं है कि फ्री / डिलीट करने के लिए कॉल नहीं है।
19

2
तो यह वास्तव में एक स्मृति रिसाव नहीं है। एक स्मृति रिसाव अप्रयुक्त लेकिन अप्रयुक्त स्मृति की छोटी मात्रा है, यह राशि समय के साथ अधिक हो जाती है। आप जिस बारे में बात कर रहे हैं वह एक मेमोरी ड्रॉपलेट है। जब तक आपकी छोटी बूंद बहुत बड़ी न हो जाए, तब तक खुद से इसकी चिंता न करें।
vfilby

"अगर यह समस्या का कारण नहीं है, तो क्या यह वास्तव में मायने रखता है?" नहीं, यह बिल्कुल भी मायने नहीं रखता। काश और लोग मिल जाते जो धार्मिक होने के बजाय।
Imbue

2
@ जॉन: यह आमतौर पर कम आलसी डेवलपर्स का सवाल है और सॉफ्टवेयर विकसित करने का सवाल है। हम सभी गलतियाँ करते हैं, कीड़े हमारे व्यापार हैं; हम उन्हें बनाते हैं हम उन्हें ठीक करते हैं, यही हम करते हैं। यह हमेशा अग्रिम लागत और दीर्घकालिक रखरखाव के बीच एक संतुलन है, यह संतुलन कभी भी सीधा नहीं होता है।
vfilby

1
जॉन, मैं 100% आपके साथ सहमत हूं .. इमबम सवाल लगभग "आप कितना स्वीकार करते हैं"। मैला, मैला है .. मैं कैसे अपने मॉनीटर के पीछे एक झींगा छोड़ दूं। बदबू बदबू है। हर बार जब हम गुफा में जाते हैं, तो हमारे उद्योग में थोड़ी बहुत कमी होती है। यदि आप जानते हैं कि एक रिसाव है और आप जानते हैं कि आपने इसका कारण बनाया है, तो आपको इसे ठीक करना चाहिए।
baash05

37

बहुत से लोग इस धारणा के तहत होते हैं कि एक बार जब आप मुफ्त मेमोरी देते हैं, तो यह तुरंत ऑपरेटिंग सिस्टम पर वापस आ जाता है और अन्य कार्यक्रमों द्वारा उपयोग किया जा सकता है।

यह सच नहीं है। ऑपरेटिंग सिस्टम आमतौर पर 4KiB पृष्ठों में मेमोरी का प्रबंधन करता है। mallocऔर स्मृति प्रबंधन के अन्य प्रकार ओएस से पेज प्राप्त करते हैं और उन्हें फिट देखते हुए उप-प्रबंधन करते हैं। यह काफी संभावना है कि ऑपरेटिंग सिस्टम पर पृष्ठों को वापस नहीं कियाfree() जाएगा , इस धारणा के तहत कि आपका कार्यक्रम बाद में अधिक मेमोरी को मैलोड करेगा।

मैं यह नहीं कह रहा हूं कि free()ऑपरेटिंग सिस्टम में मेमोरी वापस नहीं आती है। यह हो सकता है, खासकर यदि आप स्मृति के बड़े हिस्सों को मुक्त कर रहे हैं। लेकिन इसकी कोई गारंटी नहीं है।

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

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

समाप्ति से ठीक पहले मेमोरी को ख़राब करने के बारे में अधिक विवरण के लिए इस टिप्पणी को भी देखें ।

एक टिप्पणीकार को यह समझ में नहीं आया कि कॉलिंग free()स्वचालित रूप से अन्य कार्यक्रमों को मुक्त मेमोरी का उपयोग करने की अनुमति नहीं देता है। लेकिन इस जवाब के पूरे बिंदु है!

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

मान लीजिए कि आप दस हजार 100-बाइट ब्लॉक आवंटित करते हैं (सादगी के लिए मैं इन आवंटन को प्रबंधित करने के लिए आवश्यक अतिरिक्त मेमोरी की उपेक्षा करूंगा)। यह 1MB, या 250 पृष्ठों की खपत करता है। यदि आप यादृच्छिक रूप से इन ब्लॉकों के 9000 मुक्त करते हैं, तो आप सिर्फ 1000 ब्लॉकों के साथ बचे हैं - लेकिन वे सभी जगह बिखरे हुए हैं। सांख्यिकीय रूप से, लगभग 5 पृष्ठ खाली होंगे। अन्य 245 में से प्रत्येक में कम से कम एक आवंटित ब्लॉक होगा। स्मृति के 980KB की मात्रा, जो संभवतः ऑपरेटिंग सिस्टम द्वारा पुनर्प्राप्त नहीं की जा सकती है - भले ही अब आपको केवल 100KB आवंटित किया गया हो!

दूसरी ओर, अब आप अपने प्रोग्राम को बांधने वाली मेमोरी की मात्रा को बढ़ाए बिना 9000 ब्लॉक कर सकते हैं।

यहां तक कि जब free()सकता है तकनीकी रूप से ओएस के लिए स्मृति लौटने के लिए, यह ऐसा नहीं हो सकता। free()जल्दी से संचालन और स्मृति को बचाने के बीच एक संतुलन हासिल करने की जरूरत है। और इसके अलावा, एक कार्यक्रम जिसने पहले से ही बहुत सारी मेमोरी आवंटित की है और फिर इसे मुक्त कर दिया है, ऐसा फिर से करने की संभावना है। एक वेब सर्वर को अनुरोध के बाद अनुरोध को संभालने की आवश्यकता है - यह कुछ "सुस्त" मेमोरी को उपलब्ध रखने के लिए समझ में आता है ताकि आपको हर समय मेमोरी के लिए ओएस से पूछने की आवश्यकता न हो।


1
क्या होगा अगर, अन्य कार्यक्रमों के लिए मेमोरी की आवश्यकता होती है जिसे आपका प्रोग्राम अनावश्यक रूप से पकड़ रहा है, इसलिए भले ही आपको किसी भी अधिक मॉलस्क की आवश्यकता न हो, मुफ्त () अप्रयुक्त मेमोरी स्पेस :)
MN

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

27

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

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

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


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

PHP के पुराने संस्करणों ने मेमोरी जारी नहीं की, वे बस शुरू से अंत तक स्मृति में बढ़ते रहे - आमतौर पर निष्पादन समय के 0.1 सेकंड के बाद, स्क्रिप्ट बाहर निकल जाएगी, और सभी मेमोरी को पुनः प्राप्त किया जाएगा।
अरफांगियन

19

मेरा मानना ​​है कि उत्तर नहीं है, कभी भी स्मृति रिसाव की अनुमति न दें, और मेरे पास कुछ कारण हैं जिन्हें मैंने स्पष्ट रूप से नहीं देखा है। यहाँ महान तकनीकी उत्तर हैं, लेकिन मुझे लगता है कि असली उत्तर अधिक सामाजिक / मानवीय कारणों पर टिका है।

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

यहां आपके निर्णय का महत्वपूर्ण क्रुक्स आदत है। जब आप एक भाषा का उपयोग करता है कि संकेत दिए गए हैं, तो आप संकेत का उपयोग करने के लिए जा रहे हैं में कोड एक बहुत । और संकेत खतरनाक हैं; वे आपके कोड में गंभीर समस्याओं के सभी प्रकार को जोड़ने का सबसे आसान तरीका हैं।

जब आप कोडिंग करते हैं, तो कभी-कभी आप गेंद पर जा रहे हैं और कभी-कभी आप थके हुए या पागल या चिंतित होने वाले हैं। उन कुछ विचलित समयों के दौरान, आप ऑटोपायलट पर अधिक कोडिंग कर रहे हैं।ऑटोपायलट प्रभाव एक बंद कोड और एक बड़ी परियोजना में एक मॉड्यूल के बीच अंतर नहीं करता है। उन समयों के दौरान, आपके द्वारा स्थापित की जाने वाली आदतें आपके कोड आधार में समाप्त हो जाएंगी।

तो नहीं, कभी भी स्मृति को उसी कारण से लीक न होने दें, जब आप गलियों को बदल रहे हों तब भी आपको अपने अंधे धब्बों की जांच करनी चाहिए, भले ही आप इस समय सड़क पर एकमात्र कार हों। ऐसे समय के दौरान जब आपका सक्रिय मस्तिष्क विचलित होता है, अच्छी आदतें होती हैं, जो आपको विनाशकारी गलत कामों से बचा सकती हैं।

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

एक और सामाजिक पहलू भी है। के समुचित उपयोग करके malloc()और free(), कोई भी व्यक्ति आपकी कोड को देखती है आराम से हो जाएगा; आप अपने संसाधनों का प्रबंधन कर रहे हैं। यदि आप, हालांकि, वे तुरंत एक समस्या पर शक नहीं करेंगे।

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

अंत में, प्रोग्रामिंग एक अस्पष्ट भाषा के लिए एक प्रक्रिया का मानसिक मॉडल लिख रहा है ताकि एक व्यक्ति और एक कंप्यूटर पूरी तरह से उक्त प्रक्रिया को समझ सके। अच्छा प्रोग्रामिंग अभ्यास का एक महत्वपूर्ण हिस्सा कभी भी अनावश्यक अस्पष्टता का परिचय नहीं देता है।

स्मार्ट प्रोग्रामिंग लचीली और सामान्य है। खराब प्रोग्रामिंग अस्पष्ट है।


मुझे आदत विचार से प्यार है। मैं भी सहमत हूं। यदि मुझे मेमोरी लीक दिखाई देती है, तो मुझे हमेशा आश्चर्य होता है कि कोडर ने दूसरे कोने में क्या कटौती की। खासकर अगर यह स्पष्ट है
baash05

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

15

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

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

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

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


3
"लेकिन आपको निश्चित रूप से दस्तावेज करने की आवश्यकता है कि स्मृति रिसाव एक सचेत निर्णय है।" भगवान् का शुक्र है। अब तक का सबसे अच्छा बिंदु।
pestophagous

15

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

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

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

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


5
रेमंड चेन के इस उद्धरण से प्यार करें: "इमारत को ध्वस्त किया जा रहा है। फर्श को साफ करने और कचरे के डिब्बे को खाली करने और व्हाइटबोर्ड को मिटाने के लिए परेशान न करें। और इमारत से बाहर निकलने के लिए लाइन न लगाएं, ताकि हर कोई अपना स्थान बदल सके। बाहर चुंबक बाहर। आप कर रहे हैं सभी विध्वंस टीम इन व्यर्थ गृह व्यवस्था कार्यों को पूरा करने के लिए आपका इंतजार कर रही है। " ( blogs.msdn.microsoft.com/oldnewthing/20120105-00/?p=8683 )
एंड्रियास

11

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

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


यह वास्तव में सॉफ्टवेयर उम्र बढ़ने का एक उदाहरण है। अध्ययन का आकर्षक विषय।
कोनराड रूडोल्फ

एक स्वचालित रिबूट हर इतनी बार, हुह? नासा, हुह? (* पुराने माइक्रोसॉफ्ट विंडोज इंस्टॉलेशन सीडी को देखता है *) यह बहुत कुछ समझाता है ...
क्रिश्चियन सेवेरिन

8

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


वास्तव में नहीं, क्योंकि अगर यह अप्रयुक्त है, तो यह बस बाहर निकल जाएगा। जब ऐप बाहर निकलता है, तो सभी मेमोरी रिलीज़ होती है।
ग्रहण

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

बेशक यह होगा - कि आभासी स्मृति क्या है। आपके पास 1 जीबी की वास्तविक रैम हो सकती है, और अभी तक 4 प्रक्रियाएं हैं जिनमें से प्रत्येक में पूरी तरह से 2 जीबी वर्चुअल मेमोरी आवंटित की जाती है (इसलिए जब तक आपकी पेज फ़ाइल काफी बड़ी है)।
ग्रहण

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

ठीक है, मैं समझता हूँ कि आप अभी क्या बात कर रहे हैं। यदि आप मेमोरी का उपयोग कर रहे हैं, तो आप पेजिंग की आवश्यकता को कम कर देंगे। यदि आप इसे आबंटित रखते हैं, तो आपका आवेदन अभी भी इसे तब रखा जाएगा जब इसे वापस पृष्ठांकित किया जाएगा।
बिल द छिपकली

8

मैं एक तरफ "सौम्य" लीक की संख्या को गिन सकता हूं जो मैंने समय के साथ देखा है।

तो इसका जवाब बहुत ही योग्य हाँ है।

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

मैंने इस दृष्टिकोण को बहुत स्पष्ट रूप से तय की गई चीज़ों जैसे कि सीपीयू वर्क-चोरी करने वाले देवताओं के लिए बहुत लाभ के लिए इस्तेमाल किया है, और /proc/self/mapsहंस में बोहेम के रूढ़िवादी कचरा कलेक्टर में सिंगलटन राज्य को धारण करने के लिए उपयोग किए जाने वाले बफर में बहुत कम डिग्री के लिए उपयोग किया है। / C ++, जिसका उपयोग रूट सेट आदि का पता लगाने के लिए किया जाता है।

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


1
आप रिसाव को रोकने के लिए खतरनाक बिंदुओं का उपयोग कर सकते हैं।
डेमी

8

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

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

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


क्षमा करें मैं असहमत हूं। यही कारण है कि है "एक स्मृति रिसाव से प्रति"।
कोनराड रूडोल्फ

यह तब तक रिसाव नहीं है जब तक आप ऑब्जेक्ट के संदर्भ को "खो" नहीं देते हैं। संभवतः, यदि मेमोरी का उपयोग कार्यक्रम के जीवनकाल के लिए किया जाता है, तो यह लीक नहीं हुआ है। यदि संदर्भ को बाहर निकलने तक नहीं खोया जाता है () कहा जाता है, तो यह बिल्कुल रिसाव नहीं है।
nsayer

अमिगा डॉस आखिरी ओ / एसआई था जिसने देखा कि प्रक्रियाओं के पीछे सफाई नहीं हुई। ध्यान रहे, हालाँकि, सिस्टम V IPC साझा की गई मेमोरी को इधर-उधर छोड़ा जा सकता है, भले ही कोई प्रक्रिया उसका उपयोग न कर रही हो।
जोनाथन लेफलर

जब तक आप hotsync नहीं करते, पाम "मेमोरी लीक" नहीं करता। यह अमीगा के बाद अच्छी तरह से आया। मैंने अपने हथेली एमुलेटर पर ऐप चलाए हैं जिनमें लीक थे .. कभी भी उन्होंने मेरी वास्तविक हथेली पर अपना रास्ता नहीं बनाया।
baash05

6

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

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

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

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


2
बहुत अदूरदर्शी रवैया। आप मूल रूप से कह रहे हैं कि बुनियादी रूप से ध्वनि प्रोग्रामिंग प्रथाओं का उपयोग करने की कोई आवश्यकता नहीं है जब तक कि उन प्रथाओं के कारण कोई दोष नहीं पाया जाता है। समस्या यह है कि सॉफ्टवेयर है कि मैला तरीकों का उपयोग कर लिखा है सॉफ्टवेयर की तुलना में अधिक दोष है कि नहीं है।
जॉन डिबलिंग

1
मुझे विश्वास नहीं है कि सभी। और स्वच्छ तरीके लिखने की तुलना में स्मृति प्रबंधन अधिक जटिल है।
डस्टिन गेट्ज़

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

इस दृष्टिकोण के साथ समस्या यह है: आप लीक को कब ठीक करना शुरू करते हैं? "ठीक है, यह एक पावरप्लांट है, लेकिन यह केवल कोयला है, यूरेनियम नहीं। यहां लीक क्यों ठीक करें?" - मैंने वास्तविक दुनिया में सीखा है कि यदि आप बहुत शुरुआत से ही सही काम नहीं करते हैं, तो यह कभी नहीं होता है। यह रवैया दो सप्ताह के बाद "99% पूर्ण" परियोजनाओं को जन्म देता है और दो महीने तक ऐसा ही रहता है।
पियरचिन

5

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

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

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


5

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

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

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

अंततः, मैंने फैसला किया कि एक ऐप के लिए 150 बाइट्स लीक करना, जो कि एक गिग के आस-पास इस्तेमाल किया गया था और एक समर्पित मशीन पर चलता था, इसे ठीक करने के लायक नहीं था, इसलिए मैंने एक टिप्पणी लिखी कि इसे लीक किया गया था, जिसे ठीक करने के लिए बदलने की आवश्यकता थी यह, और क्यों उस समय इसके लायक नहीं था।


होशियार। विशेष रूप से चूंकि रिसाव आरंभीकरण के दौरान था, जिसका अर्थ है कि यह एप्लिकेशन के रनटाइम पर जमा नहीं होगा।
डेमी

5

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

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

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

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

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


वाह ... कोई है जो जानता है कि स्मृति रिसाव क्या है।
साइमन बुकान

4

मैं vfilby से सहमत हूं - यह निर्भर करता है। विंडोज में, हम मेमोरी लीक को अपेक्षाकृत गंभीर कीड़े के रूप में मानते हैं। लेकिन, यह बहुत घटक पर निर्भर करता है।

उदाहरण के लिए, मेमोरी लीक उन घटकों के लिए बहुत गंभीर नहीं है जो शायद ही कभी चलते हैं, और सीमित समय के लिए। ये घटक चलते हैं, काम करते हैं, फिर बाहर निकलते हैं। जब वे बाहर निकलते हैं, तो उनकी सारी याददाश्त से मुक्ति मिल जाती है।

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

इसलिए, यदि आपके पास रिसाव है - इसके प्रभाव का मूल्यांकन दो तरीकों से करें

  1. आपके सॉफ़्टवेयर और आपके उपयोगकर्ता के अनुभव के लिए।
  2. सिस्टम संसाधनों के साथ मितव्ययी होने के संदर्भ में सिस्टम (और उपयोगकर्ता) के लिए।
  3. रखरखाव और विश्वसनीयता पर प्रभाव का प्रभाव।
  4. कहीं और प्रतिगमन पैदा करने की संभावना।

Foredecker


3. सॉफ्टवेयर के रखरखाव पर प्रभाव।
पेट्रचन डेस

3

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

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


3

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

KIV


3

मुझे लगता है कि यह ठीक है यदि आप मेमोरी को लीक करने के लिए एक प्रोग्राम लिख रहे हैं (यानी सिस्टम प्रदर्शन पर मेमोरी लीक के प्रभाव का परीक्षण करने के लिए)।


3

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

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

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

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

जैसा कि मौजूदा या तीसरे पक्ष के कोड के बारे में है, जहां बदलाव की गुणवत्ता या क्षमता पर आपका नियंत्रण अत्यधिक सीमित हो सकता है, रिसाव की गंभीरता के आधार पर, आपको स्वीकार करने या कार्रवाई को कम करने के लिए मजबूर किया जा सकता है जैसे कि आपकी प्रक्रिया को कम करने के लिए नियमित रूप से पुनः आरंभ करना। रिसाव का प्रभाव।

मौजूदा (लीक) कोड को बदलना या बदलना संभव नहीं हो सकता है, और इसलिए आप इसे स्वीकार करने के लिए बाध्य हो सकते हैं। हालाँकि, यह घोषित करने के समान नहीं है कि यह ठीक है।


2

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


2

मुझे लगता है कि आपने अपने प्रश्न का उत्तर दे दिया है। सबसे बड़ी कमी यह है कि वे स्मृति रिसाव का पता लगाने वाले उपकरणों में कैसे हस्तक्षेप करते हैं, लेकिन मुझे लगता है कि कुछ प्रकार के अनुप्रयोगों के लिए एक बड़ी कमी है।

मैं लीगेसी सर्वर एप्लिकेशन के साथ काम करता हूं, जो रॉक सॉलिड होने चाहिए लेकिन उनके पास लीक हैं और ग्लोबल्स डीओ मेमोरी मेमोरी टूल्स के रास्ते में आते हैं। यह एक बड़ा सौदा है।

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


2

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


उस स्थिति में स्मृति रिसाव का प्रभाव बदल जाता है, और आपको रिसाव को प्लग करने की प्राथमिकता का पुनर्मूल्यांकन करने की आवश्यकता होती है।
जॉन डिब्लिंग

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

2

मैं जवाब नहीं दूंगा।

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

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


2

ऐतिहासिक रूप से, यह कुछ किनारे के मामलों के तहत कुछ ऑपरेटिंग सिस्टम पर बात करता था। ये किनारे भविष्य में मौजूद हो सकते हैं।

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


2

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


लेकिन अगर आप एक ऐसे इंजन वाले कार के मालिक हैं जो कभी-कभी तेल लीक करता है, तो क्या आप इसे ठीक करने के लिए पैसे खर्च करते हैं, या क्या आप तेल के स्तर पर नज़र रखते हैं और समय-समय पर इसे ऊपर उठाते हैं। उत्तर सभी प्रकार के कारकों पर निर्भर करता है।
स्लिम

यह एक कार के मालिक के बारे में नहीं है। यह एक कार बनाने के बारे में है। यदि आपको मेमोरी लीक के साथ एक तृतीय-पक्ष लाइब्रेरी मिलती है और आपको इसका उपयोग करना है, तो आप इसके साथ रहते हैं। लेकिन अगर आप एक सिस्टम या लाइब्रेरी लिख रहे हैं, तो यह सुनिश्चित करना आपकी ज़िम्मेदारी है कि यह बग-मुक्त है।
दिमा

+1 इसे किसी अन्य बग की तरह ट्रीट करें। (इसका मतलब यह नहीं है कि मेरी पुस्तक में "तुरंत ठीक करें", लेकिन "सुनिश्चित करने के लिए" उपसर्ग करने की आवश्यकता है)
peterchen

2

आमतौर पर एक स्टैंड अलोन एप्लीकेशन में मेमोरी लीक होना घातक नहीं है, क्योंकि प्रोग्राम से बाहर निकलने पर यह साफ हो जाता है।

आप सर्वर प्रोग्राम के लिए क्या करते हैं जो डिज़ाइन किए गए हैं ताकि वे बाहर न निकलें?

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

उस मेमोरी को लीक करें और प्रोग्राम को साफ करने दें? नहीं, बिल्कुल नहीं। यह एक बुरी आदत है, जो कीड़े, कीड़े और अधिक कीड़े की ओर जाता है।

अपने आप के बाद साफ करो। यो माँ यहाँ कोई और काम नहीं करते।


मैंने सर्वर कार्यक्रमों पर काम किया है जो थ्रेड्स के बजाय जानबूझकर प्रक्रियाओं का उपयोग करते हैं, ताकि मेमोरी लीक और विभाजन दोष सीमित नुकसान का कारण बनें।
स्लिम

दिलचस्प दृष्टिकोण। मैं उन प्रक्रियाओं के बारे में थोड़ा चिंतित रहूंगा जो बाहर निकलने में विफल रहती हैं और स्मृति को बनाए रखना जारी रखती हैं।
ईविलटच

2

एक सामान्य नियम के रूप में, यदि आपको मेमोरी लीक्स मिल गया है जिसे आप महसूस करते हैं कि आप बच नहीं सकते हैं, तो आपको वस्तु स्वामित्व के बारे में अधिक कठिन सोचने की आवश्यकता है।

लेकिन आपके सवाल के लिए, संक्षेप में मेरा जवाब है उत्पादन कोड में है, हाँ। विकास के दौरान, नहीं । यह पीछे की ओर लग सकता है, लेकिन यहाँ मेरा तर्क है:

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.