मेमोरी लीक

Question

खोजने के लिए 'लीक' कमांड लाइन उपयोगिता को समझना मैं अपने आईफोन प्रोग्राम में मेमोरी लीक खोजने में कुछ मुश्किलों को ट्रैक करने पर काम कर रहा हूं। मैं जो निम्नलिखित जानबूझकर -incorrect- कोड के साथ एक NSString वस्तु लीक एक ऐप्लिकेशन पर एक त्वरित परीक्षण चल रहा हूँ:

-(void)applicationDidFinishLaunching:(NSNotification *)notification; 
{ 
    NSMutableString *test = [[NSMutableString alloc] init]; 
    [test appendString:@"Testing 1"]; 
    [test appendString:@"\nTesting 2"]; 
    NSLog(@"%@", test); 

    // Uncomment the following line to release the 
    // string and clean up your leak. 
    // [test release], test = nil; 
} 

आवेदन की प्रक्रिया आईडी पर लीक चलाने के बाद, मैं निम्नलिखित के साथ आते हैं:

sf$ leaks 3951 
Process 3951: 9988 nodes malloced for 1260 KB 
Process 3951: 3 leaks for 128 total leaked bytes. 
Leak: 0x163b50 size=64 instance of 'NSCFDictionary', type ObjC, implemented in Foundation 
    0xa07e0720 0x01001080 0x0000000a 0x00000010  .~............. 
    0x0000000a 0x0000000c 0x0000000b 0x00000000  ................ 
    0x00000000 0x00000015 0xa1b1c1d3 0x00163b90  .............;.. 
    0x00163bd0 0x00000000 0x00000000 0x00000000  .;.............. 
Leak: 0x178190 size=32 string 'Testing 1 
Testing 2' 
Leak: 0x178210 size=32 instance of 'NSCFString', type ObjC, implemented in CoreFoundation 
    0xa02e24a0 0x010007ad 0x00178190 0x00000013  .$.............. 
    0x00000020 0x00000200 0x00000000 0x00000000  ............... 

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

वे ऑब्जेक्ट्स हैं जो स्मृति पते 0x163b50, 0x178190, 0x178210 पर स्थित हैं। उनका कार्यान्वयन ऐप्पल ढांचे में है, न कि मेरे कोड - 'लीक' के अनुसार। एक छोटे उदाहरण में जैसे कि निम्नलिखित, रिसाव ढूंढना मुश्किल नहीं है। हालांकि, कोड के 500 के लाइनों के साथ एक आवेदन में, मुझे बेकार से उत्पादन बेकार लगता है।

मैं क्या गलत कर रहा हूं और मैं अपने आउटपुट लीक को साफ करने के लिए लिखे गए कोड में अपराधी को ढूंढने में मदद करने के लिए इस आउटपुट को कैसे समझ सकता हूं?

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

धन्यवाद सब कुछ।

EDIT: लीक को साफ करने के लिए लाइनों को अपूर्ण करने के बाद भी, 'लीक' उपयोगिता लीक होने पर भी इससे अधिक शिकायत करती है। क्या फाउंडेशन/कोको इस तरह के एक छोटे से उदाहरण से ज्यादा लीक कर रहा है? यह ऊपर परीक्षण स्ट्रिंग के लिए विज्ञप्ति जारी की uncommenting के बाद होता है:

sf$ leaks 4383 
Process 4383: 9890 nodes malloced for 1255 KB 
Process 4383: 7 leaks for 560 total leaked bytes. 
Leak: 0x163920 size=176 instance of 'NSPathStore2', type ObjC, implemented in Foundation  
    0xa07e2ae0 0x04f00000 0x0055002f 0x00650073  .*~...../.U.s.e. 
    0x00730072 0x0073002f 0x002f0066 0x0069004c  r.s./.s.f./.L.i. 
    0x00720062 0x00720061 0x002f0079 0x00700041  b.r.a.r.y./.A.p. 
    0x006c0070 0x00630069 0x00740061 0x006f0069  p.l.i.c.a.t.i.o. 
    0x0020006e 0x00750053 0x00700070 0x0072006f  n. .S.u.p.p.o.r. 
    0x002f0074 0x00490053 0x0042004d 0x002f004c  t./.S.I.M.B.L./. 
    0x006c0050 0x00670075 0x006e0069 0x002f0073  P.l.u.g.i.n.s./. 
    0x00650054 0x006d0072 0x006e0069 0x006c0061  T.e.r.m.i.n.a.l. 
    ... 
Leak: 0x163350 size=160 instance of 'NSPathStore2', type ObjC, implemented in Foundation  
    0xa07e2ae0 0x04a00000 0x0055002f 0x00650073  .*~...../.U.s.e. 
    0x00730072 0x0073002f 0x002f0066 0x0069004c  r.s./.s.f./.L.i. 
    0x00720062 0x00720061 0x002f0079 0x00700041  b.r.a.r.y./.A.p. 
    0x006c0070 0x00630069 0x00740061 0x006f0069  p.l.i.c.a.t.i.o. 
    0x0020006e 0x00750053 0x00700070 0x0072006f  n. .S.u.p.p.o.r. 
    0x002f0074 0x00490053 0x0042004d 0x002f004c  t./.S.I.M.B.L./. 
    0x006c0050 0x00670075 0x006e0069 0x002f0073  P.l.u.g.i.n.s./. 
    0x00650044 0x0069006c 0x00690063 0x0075006f  D.e.l.i.c.i.o.u. 
    ... 
Leak: 0x1635a0 size=64 instance of 'NSCFDictionary', type ObjC, implemented in Foundation 
    0xa07e0720 0x01001080 0x0000000a 0x00000010  .~............. 
    0x0000000a 0x0000000c 0x0000000b 0x00000000  ................ 
    0x00000000 0x00000015 0xa1b1c1d3 0x001635e0  .............5.. 
    0x00163620 0x00000000 0x00000000 0x00000000  6.............. 
Leak: 0x163620 size=64 
    0xa02ed360 0x00160ee0 0x00163700 0xa02efc00  `........7...... 
    0x00000000 0x00000000 0x00163680 0x00000000  .........6...... 
    0x00000000 0x00000000 0x00163660 0xa02ed440  ........`6..@... 
    0xa02ec1a0 0xa02f0420 0x00000000 0x00163660  .... ./.....`6.. 
Leak: 0x163680 size=48 instance of 'NSCFString', type ObjC, implemented in CoreFoundation 
    0xa02e24a0 0x0100078c 0x6d6f6323 0x6c65642e  .$......#com.del 
    0x6f696369 0x61737375 0x69726166 0x6c65442e  icioussafari.Del 
    0x6f696369 0x61537375 0x69726166 0x00000000  iciousSafari.... 
Leak: 0x163660 size=32 instance of 'NSCFString', type ObjC, implemented in CoreFoundation 
    0xa02e24a0 0x0200078c 0x6c65440f 0x6f696369  .$.......Delicio 
    0x61537375 0x69726166 0x00000000 0x00000000  usSafari........ 
Leak: 0x160ee0 size=16 instance of 'NSCFString', type ObjC, implemented in CoreFoundation 
    0xa02e24a0 0x0100078c 0x362e3103 0x00000000  .$.......1.6.... 

Answer 1

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

पता लगाने के लिए जहां किसी चीज़ से आवंटित, लीक के परिवेश में MallocStackLogging स्थापित किया गया था:

% MallocStackLogging=1 leaks … 

तुम भी -nocontent विकल्प है, जो हेक्स डंप को दबाने का उपयोग कर सकते हैं। इस समय हर समय उपयोग न करें, हालांकि: कभी-कभी हेक्स डंप में एक मूल्यवान सुराग होता है।

इसके अलावा, लीक आपको यह नहीं बताती कि आपके पास तीन रिसाव हैं; सटीक होने के लिए, यह आपको बता रहा है कि आपके पास तीन लीक ऑब्जेक्ट्स हैं। आपके द्वारा दिखाए गए जानबूझकर रिसाव में केवल एक लीक ऑब्जेक्ट उत्पन्न होता है, लेकिन एक अलग रिसाव (जैसे लूप या अक्सर बुलाया गया विधि) कई ऑब्जेक्ट्स को रिसाव कर सकता है।

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

Answer 2

इस उदाहरण के लिए, 128 बाइट्स की कुल के लिए रिपोर्ट 3 लीक लीक।

1) यदि आप एक NSMutableString जो 64 बाइट्स

2) यदि आप 32 बाइट्स

के लिए कुल परीक्षण 1 लीक कर रहे हैं के लिए कुल NSCFDictionary के रूप में आंतरिक रूप से लागू किया जाना प्रतीत होता है लीक कर रहे हैं: व्याख्या इस रूप में होना चाहिए

3) यदि आप 32 बाइट्स

इसका कारण यह है कि अगर आप अपने NSMutableString जारी नहीं करते होना चाहिए के लिए कुल \ nTesting 2 लीक कर रहे हैं, वस्तुओं में से कोई भी (इस मामले में तार) NSCFDictionary डेटा संरचना से संबंधित होगा जारी किया जाना चाहिए: जब भी आप appendString विधि का उपयोग करते हैं, तब तक उन्हें बनाए रखा जाता है। जब आप अपना एनएसएमयूटेबलस्ट्रिंग जारी करते हैं, तो एनएससीएफ डिक्शनरी के अंदर की सभी ऑब्जेक्ट स्वचालित रूप से एनएससीएफ डिक्शनरी के साथ जारी की जाती हैं।

एप्पल प्रलेखन (http://developer.apple.com/iPhone/library/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html) से:

तो एक कोको वस्तु जगह में एक autorelease पूल बिना autoreleased है, Xcode सांत्वना चेतावनी है कि वस्तु सिर्फ लीक कर रहा है के लिए एक संदेश भेजता है। भले ही आप कोको एप्लिकेशन नहीं लिख रहे हैं, फिर भी इस तरह की कंसोल चेतावनी देखना संभव है।कई कोको कक्षाओं का कार्यान्वयन कोर फाउंडेशन प्रकारों पर आधारित है। यदि आपका एप्लिकेशन कोर फाउंडेशन का उपयोग करता है, तो यह संभव है कि उस ढांचे पर कॉल के परिणामस्वरूप लीक हो रहे हों।

इस प्रकार की मेमोरी लीक खोजने के लिए, _NSAutoreleaseNoPool फ़ंक्शन पर ब्रेकपॉइंट डालने के लिए डीबगर का उपयोग करें। यह फ़ंक्शन फाउंडेशन ढांचे में NSDebug.h में घोषित किया गया है। जब डीबगर उस फ़ंक्शन तक पहुंच जाता है, तो आपको स्टैक क्रॉल को देखने में सक्षम होना चाहिए और देखें कि कोड का किस टुकड़े रिसाव का कारण बनता है।

Answer 3

मुझे लगता है कि आप इसे लीक में देख रहे हैं क्योंकि appendStringautorelease आंतरिक रूप से उपयोग कर रहा है। ऑटोरेलीज पूल को अगले 'ईवेंट' तक नहीं छोड़ा जा रहा है। असल में, मुझे लगता है कि नमूना सटीक रूप से दिखाने के लिए बहुत आसान है कि क्या हो रहा है।

मैं यहां बेस से बाहर निकल सकता हूं, लेकिन मैं अपने कोड को एक ऑटोरेलीज पूल में लपेटने की कोशिश करता हूं ताकि यह देखने के लिए कि क्या परिवर्तन हो।

-(void)applicationDidFinishLaunching:(NSNotification *)notification; 
{ 
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; 
    NSMutableString *test = [[NSMutableString alloc] init]; 
    [test appendString:@"Testing 1"]; 
    [test appendString:@"\nTesting 2"]; 
    NSLog(@"%@", test); 
    [test release], test = nil; 
    [pool release] // this should drain the autorelease pool 
}