2010-10-22 14 views
6

मुझे NSOperationQueue में अनुरोध रद्द करने का प्रयास करते समय वास्तव में कठिन समय हो रहा है।ऑपरेशन रद्द करते समय ASIHTTPRequest और NSOperationQueue के साथ क्रैशिंग

मेरी 'इंजन' ऑब्जेक्ट को हटाने से पहले, मैं कतार में सबकुछ रद्द करने के लिए एक रद्दऑपरेशन विधि को कॉल करता हूं, इसलिए इसमें उड़ान ASIHTTPRequests और queued वाले शामिल होंगे ... उदा।

Engine.m

-(void)getContent { 
    if (![self queue]) { 
     [self setQueue:[[[NSOperationQueue alloc] init] autorelease]]; 
    } 

    NSURL *url = [NSURL URLWithString:@"http://allseeing-i.com"]; 
    ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; 
    [request setDelegate:self]; 
    [request setDidFinishSelector:@selector(requestDone:)]; 
    [[self queue] addOperation:request]; //queue is an NSOperationQueue 
} 

-(void)requestDone:(ASIHTTPRequest)*request { 

    // Do something with request 
} 

-(void)cancelOperations { 
    [self.queue cancelAllOperations]; 
    [self.queue waitUntilAllOperationsAreFinished]; 
} 

-(void)dealloc { 
    [super dealloc]; 
} 

अब, मेरी इंजन में मैं getContent प्रकार की अनेक विधियों का है, इसलिए मेरी कतार में अलग अनुरोध वस्तुएं हैं की है। प्रवाह जब एक इंजन वस्तु का उपयोग कर रहा है:

1) ओपन देखें नियंत्रक - दृश्य लोड था - alloc और init इंजन वस्तु
2) // विभिन्न getContent शैली तरीकों कॉल दृश्य पर कुछ कार्यों
3) ऊपर क़तार में बाहर निकलें, कॉल करें [इंजन रद्द करेंऑपरेशंस]; (ए) उड़ान में किसी भी नेटवर्क अनुरोध को रोकें, और कतार
4 को खाली करने के लिए 4) दृश्य को हटा दें, और उसके साथ इंजन: [इंजन रिलीज];

यह ठीक काम करता है अगर सभी अनुरोध कतार में समाप्त हो गए हैं (जैसा कि यह खाली है), हालांकि अगर मैं रद्द करता हूं तो अनुरोध रद्द हो जाता है, एप्लिकेशन EXC_BAD_ACCESS त्रुटि के साथ क्रैश हो जाता है ... लेकिन इंजन को सफलतापूर्वक हटा दिया जाता है ..

कोई विचार यह क्यों होगा?

--EDIT-- त्रुटि के लिए पश्व-अनुरेखन जोड़ना:

[request setDelegate:self];:

Exception Type: EXC_BAD_ACCESS (SIGBUS) 
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000b0000000 
Crashed Thread: 0 Dispatch queue: com.apple.main-thread 

Application Specific Information: 
objc_msgSend() selector name: respondsToSelector: 
iPhone Simulator 225, iPhone OS 4.1 (iPhone 4/8B117) 

Thread 0 Crashed: Dispatch queue: com.apple.main-thread 
0 libobjc.A.dylib     0x02cb5907 objc_msgSend + 27 
1 CoreFoundation     0x02ac95cd __invoking___ + 29 
2 CoreFoundation     0x02ac94a1 -[NSInvocation invoke] + 145 
3 Foundation      0x0015a3ca __NSThreadPerformPerform + 251 
4 CoreFoundation     0x02b39faf __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15 
5 CoreFoundation     0x02a9839b __CFRunLoopDoSources0 + 571 
6 CoreFoundation     0x02a97896 __CFRunLoopRun + 470 
7 CoreFoundation     0x02a97350 CFRunLoopRunSpecific + 208 
8 CoreFoundation     0x02a97271 CFRunLoopRunInMode + 97 
9 GraphicsServices    0x0320c00c GSEventRunModal + 217 
10 GraphicsServices    0x0320c0d1 GSEventRun + 115 
11 UIKit       0x003e9af2 UIApplicationMain + 1160 
12 Clicky       0x000027d4 main + 102 (main.m:14) 
13 Clicky       0x00002765 start + 53 

Thread 1: Dispatch queue: com.apple.libdispatch-manager 
0 libSystem.B.dylib    0x97cfe942 kevent + 10 
1 libSystem.B.dylib    0x97cff05c _dispatch_mgr_invoke + 215 
2 libSystem.B.dylib    0x97cfe519 _dispatch_queue_invoke + 163 
3 libSystem.B.dylib    0x97cfe2be _dispatch_worker_thread2 + 240 
4 libSystem.B.dylib    0x97cfdd41 _pthread_wqthread + 390 
5 libSystem.B.dylib    0x97cfdb86 start_wqthread + 30 

Thread 2: 
0 libSystem.B.dylib    0x97cfd9d2 __workq_kernreturn + 10 
1 libSystem.B.dylib    0x97cfdf68 _pthread_wqthread + 941 
2 libSystem.B.dylib    0x97cfdb86 start_wqthread + 30 

Thread 3: WebThread 
0 libSystem.B.dylib    0x97cd80fa mach_msg_trap + 10 
1 libSystem.B.dylib    0x97cd8867 mach_msg + 68 
2 CoreFoundation     0x02b3a436 __CFRunLoopServiceMachPort + 150 
3 CoreFoundation     0x02a97984 __CFRunLoopRun + 708 
4 CoreFoundation     0x02a97350 CFRunLoopRunSpecific + 208 
5 CoreFoundation     0x02a97271 CFRunLoopRunInMode + 97 
6 WebCore       0x034093a3 RunWebThread(void*) + 483 
7 libSystem.B.dylib    0x97d0581d _pthread_start + 345 
8 libSystem.B.dylib    0x97d056a2 thread_start + 34 

Thread 4: 
0 libSystem.B.dylib    0x97cfd9d2 __workq_kernreturn + 10 
1 libSystem.B.dylib    0x97cfdf68 _pthread_wqthread + 941 
2 libSystem.B.dylib    0x97cfdb86 start_wqthread + 30 

Thread 5: 
0 libSystem.B.dylib    0x97cd80fa mach_msg_trap + 10 
1 libSystem.B.dylib    0x97cd8867 mach_msg + 68 
2 CoreFoundation     0x02b3a436 __CFRunLoopServiceMachPort + 150 
3 CoreFoundation     0x02a97984 __CFRunLoopRun + 708 
4 CoreFoundation     0x02a97350 CFRunLoopRunSpecific + 208 
5 CoreFoundation     0x02a9a614 CFRunLoopRun + 84 
6 Clicky       0x0001fdb7 +[ASIHTTPRequest runRequests] + 167 (ASIHTTPRequest.m:4093) 
7 Foundation      0x0014576c -[NSThread main] + 81 
8 Foundation      0x001456f8 __NSThread__main__ + 1387 
9 libSystem.B.dylib    0x97d0581d _pthread_start + 345 
10 libSystem.B.dylib    0x97d056a2 thread_start + 34 

Thread 6: 
0 libSystem.B.dylib    0x97cd80fa mach_msg_trap + 10 
1 libSystem.B.dylib    0x97cd8867 mach_msg + 68 
2 CoreFoundation     0x02b3a436 __CFRunLoopServiceMachPort + 150 
3 CoreFoundation     0x02a97984 __CFRunLoopRun + 708 
4 CoreFoundation     0x02a97350 CFRunLoopRunSpecific + 208 
5 CoreFoundation     0x02a97271 CFRunLoopRunInMode + 97 
6 Foundation      0x0017ab86 +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:] + 398 
7 Foundation      0x0014576c -[NSThread main] + 81 
8 Foundation      0x001456f8 __NSThread__main__ + 1387 
9 libSystem.B.dylib    0x97d0581d _pthread_start + 345 
10 libSystem.B.dylib    0x97d056a2 thread_start + 34 

Thread 7: 
0 libSystem.B.dylib    0x97cf7086 select$DARWIN_EXTSN + 10 
1 CoreFoundation     0x02acbb5e __CFSocketManager + 798 
2 libSystem.B.dylib    0x97d0581d _pthread_start + 345 
3 libSystem.B.dylib    0x97d056a2 thread_start + 34 

Thread 8: 
0 libSystem.B.dylib    0x97cfd9d2 __workq_kernreturn + 10 
1 libSystem.B.dylib    0x97cfdf68 _pthread_wqthread + 941 
2 libSystem.B.dylib    0x97cfdb86 start_wqthread + 30 

Thread 0 crashed with X86 Thread State (32-bit): 
    eax: 0x06641500 ebx: 0x000143f3 ecx: 0x0008e1c8 edx: 0x06606075 
    edi: 0xb0000000 esi: 0x066554c4 ebp: 0xbfffdef8 esp: 0xbfffdec4 
    ss: 0x0000001f efl: 0x00010206 eip: 0x02cb5907 cs: 0x00000017 
    ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 
    cr2: 0xb0000000 

उत्तर

4

आप dealloc में अपने ऑपरेशन कतार जारी नहीं करते ...

एक संदिग्ध प्रतिनिधिमंडल पैटर्न है

यदि self ऑब्जेक्ट नष्ट हो गया है, और अनुरोध नहीं है, जब अनुरोध 'पूरा' होता है, तो यह होगा स्मृति में कुछ कचरा सूचित करने की कोशिश करें, इसलिए दुर्घटनाग्रस्त हो जाएं।

अद्यतन: इस पैच करने के लिए, रद्द करने से पहले इस कोड जोड़ें:

for (ASIHTTPRequest *request in queue.operations) 
{ 
    [request setDelegate: nil]; 
    [request setDidFinishSelector: nil]; 
} 
+0

क्या इसे ऑटोमोलीज पर सेट करने पर इसे रिलीज़ करने की आवश्यकता है? मुझे यकीन है कि मैं इंजन [इंजन रद्द करने के बाद] इंजन को नष्ट कर रहा हूं - तो क्या यह अभी भी एक मुद्दा हो सकता है? – mootymoots

+0

आप '[self setQueue: ...] 'करते हैं। मुझे लगता है कि आपके पास एक कतार संपत्ति है जो बरकरार है। यदि ऐसा नहीं है, तो यह एक बड़ा खतरा है, क्योंकि आपकी कतार किसी भी समय जारी की जा सकती है। – jv42

+0

क्षमा करें, हाँ आप सही हैं ... मेरे आत्म के बारे में क्या नष्ट? मैंने सोचा कि waitUntilAllOperationsAreFinished मेरे ऐप को जारी रखने से रोक देगा जब तक कि कतार खाली नहीं हो जाती? – mootymoots

0

सुनिश्चित करें कि आप ASIHTTPRequest के हाल के एक Git संस्करण चला रहे हैं - v1.7 कि क्रैश रद्द कारण बनता होगा दौड़ की स्थिति के एक जोड़े शामिल अनुरोध।

+0

मेरे पास नवीनतम संस्करण है जो मुझे डर रहा है ... – mootymoots

+0

ओह ठीक है, जांच करने लायक था। क्या आप अपने प्रश्न पर दुर्घटना के लिए बैकट्रैक जोड़ सकते हैं ताकि हम देख सकें कि कोड का कौन सा क्षेत्र अभी भी चल रहा है? – JosephH

+0

हाय - – mootymoots

4

मुझे लगता है कि jv42 कारण के बारे में सही है। हालांकि, वहाँ प्रतिनिधियों को साफ करने के लिए एक उपयोगी सहायक है ...

-(void)dealloc { 
    for (ASIHTTPRequest *request in queue.operations) { 
    [request clearDelegatesAndCancel]; 
    } 
    [queue release]; 
    [super dealloc]; 
} 

किसी को भी इस के लिए एक तेज विधि पाया गया है ... शायद एक है कि अनुरोध से अधिक पाशन शामिल नहीं करता है?

0

एकाधिक अनुरोधों के साथ ASINetworkQueue चलाने के दौरान मुझे वही स्थिति थी।

मैंने कतार के लिए डेलोक रिलीज को हटा दिया, और ऑटोरेलीज। इसके बाद मैंने प्रतिनिधियों को नील करने के लिए लूप के उत्कृष्ट सुझाव को लागू किया। फिर मैंने queueRequestFinished प्रतिनिधि में कतार की रिलीज डाली और यह मेरी समस्या का समाधान किया!

bulkQueue = [[ASINetworkQueue alloc] init]; 

[bulkQueue setQueueDidFinishSelector:@selector(queueRequestFinished:)]; 

-(void)queueRequestFinished:(ASINetworkQueue *)queue 
{ 
    for (ASIHTTPRequest *request in queue.operations) 
    { 
     [request setDelegate: nil]; 
     [request setDidFinishSelector: nil]; 
    } 

} 

आशा है कि इससे किसी को मदद मिलेगी! :-)

+0

से ऊपर जोड़ा गया है ओह, यह उदाहरण संस्करण 1.8.1 के लिए काम करता है और मैंने यह भी सुनिश्चित करने के लिए परीक्षण किया कि यह मेरे मामले में संभावित स्मृति रिसाव नहीं है। – August

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