2010-01-29 11 views
5

CSURLCache ऑफ़लाइन ब्राउज़िंग के लिए संसाधनों को कैश करने के लिए डिज़ाइन किया गया है, NSURLCache केवल डेटा इन-मेमोरी संग्रहीत करता है।NSURLCache ऑटोरेलेज्ड ऑब्जेक्ट्स के साथ क्रैश हो जाता है, लेकिन लीक अन्यथा

यदि cachedResponse एप्लिकेशन क्रैश को वापस करने से पहले स्वत: बंद कर दिया गया है, यदि नहीं, तो वस्तुएं बस लीक हो जाती हैं।

इस पर बहने वाले किसी भी प्रकाश की बहुत सराहना की जाएगी।

कृपया ध्यान दें stringByEncodingURLEntitiesNSString पर एक श्रेणी विधि है।

@interface CSURLCache : NSURLCache {} @end 

@implementation CSURLCache 

- (NSCachedURLResponse *)cachedResponseForRequest:(NSURLRequest *)request 
{ 
    NSString *path = [[NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES) lastObject] stringByAppendingPathComponent:[[[request URL] absoluteString] stringByEncodingURLEntities]]; 

    if ([[NSFileManager defaultManager] fileExistsAtPath:path]) 
    { 
     NSData *data = [[NSData alloc] initWithContentsOfFile:path]; 
     NSURLResponse *response = [[NSURLResponse alloc] initWithURL:[request URL] 
                  MIMEType:nil 
               expectedContentLength:[data length] 
                textEncodingName:nil]; 

     NSCachedURLResponse *cachedResponse = [[NSCachedURLResponse alloc] initWithResponse:response 
                         data:data]; 
     [response release]; 
     [data release]; 

     return cachedResponse; 
    } 

    return nil; 
} 

@end 

अद्यतन: एप्पल के लिए एक रडार जमा करने के बाद ऐसा लगता है कि यह एक ज्ञात समस्या (रडार # 7,640,470) है।

+0

क्या आप सुनिश्चित हैं कि वे लीक हो गए हैं यदि वे स्वत: नहीं हैं? और क्या आप सुनिश्चित हैं कि आपका प्रोग्राम क्रैश हो क्योंकि आप उन्हें रिलीज़ करने का प्रयास करते हैं? मेमोरी प्रबंधन नियम स्पष्ट रूप से बताते हैं कि आप उस वस्तु को जारी करने के लिए जिम्मेदार होंगे। – zneak

+3

हां, अगर वे स्वत: नहीं हैं तो वे निश्चित रूप से लीक हो रहे हैं। कार्यक्रम दुर्घटनाग्रस्त हो जाता है क्योंकि एक निरंतर संदेश को एक हटाए गए ऑब्जेक्ट –

उत्तर

1
- (NSCachedURLResponse *)cachedResponseForRequest:(NSURLRequest *)request 

खैर, यह एक alloc, new, या copy विधि ...

नहीं है ... और CSURLCache कहीं भी वस्तु पर पकड़ नहीं है, इसलिए इसे मालिक नहीं है।

तो, आपको इसे ऑटोोरलीज करने की आवश्यकता है।

बेशक, इसका मतलब है कि वस्तु तब तक बर्बाद हो जाती है जब तक कि कुछ इसे बरकरार न रखे। आपका ऐप क्रैश हो गया क्योंकि ऑब्जेक्ट की मृत्यु के बाद ऑब्जेक्ट का उपयोग करने की कोशिश की गई।

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

+0

पर भेजा जाता है ऐप क्रैश हो जाता है क्योंकि एक निरंतर संदेश को एक निरंतर ऑब्जेक्ट पर भेजा जाता है, हालांकि, बाद की जांच के साथ, कैश्ड रेस्पॉन्स नहीं। हालांकि मैं यह नहीं समझ सकता कि कौन सा ऑब्जेक्ट संदेश भेजा जा रहा है। अगर मैं NSZombie सक्षम सक्षम करता हूं तो यह प्रिंट करता है "[एक प्रकार नहीं बनाए रखें]"। –

+0

इस समाधान पर विश्वास न करें, क्योंकि NSCachedResponse उस ऑब्जेक्ट नहीं है जो इसे रिलीज़ होने पर क्रैश का कारण बन रहा है (यह इसके डेलोक के हिस्से के रूप में क्रैश हो रहा है, जिसका अर्थ है कि एनएससीएडआरडस्पॉन्स को बरकरार रखा गया है) – BadPirate

+0

outtru.mp : मेमोरी मैनेजमेंट को सही ढंग से लागू करना वैकल्पिक नहीं है (ऐसा नहीं करने का मतलब होगा कि प्रश्नकर्ता के पास दो बग होंगे), और लाश उपकरण यह है कि आप यह निर्धारित करेंगे कि किस ऑब्जेक्ट को ओवर-रिलीज़ किया गया है और क्या अतिरिक्त रिलीज था। तो, पूर्व पहलू समाधान का हिस्सा है (लीकिंग एक दुर्घटना के लिए बेहतर हो सकती है, लेकिन एक बार दुर्घटना समाप्त हो जाने पर, रिसाव भी होना चाहिए), और बाद में वास्तविक समस्या की जांच का हिस्सा है। –

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