Afnetworking: EXC_BAD_ACCESS exception
I have a thread that is crashing in CFDictionaryGetValue
The stack trace for the thread that is causing the exception is as follows:
* thread #10: tid = 0x9f8aa, 0x302ed04a CoreFoundation`CFDictionaryGetValue + 10, queue = 'NSOperationQueue 0x16d835c0, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x302ed04a CoreFoundation`CFDictionaryGetValue + 10
frame #1: 0x30d37438 Foundation`_NSSetIntValueAndNotify + 48
frame #2: 0x30041168 CFNetwork`__55-[__NSCFURLSession delegate_task:didCompleteWithError:]_block_invoke + 28
frame #3: 0x30cfd7ce Foundation`-[NSBlockOperation main] + 130
frame #4: 0x30ced97a Foundation`-[__NSOperationInternal _start:] + 770
frame #5: 0x30d91b34 Foundation`__NSOQSchedule_f + 60
frame #6: 0x3afd66de libdispatch.dylib`_dispatch_async_redirect_invoke$VARIANT$mp + 110
frame #7: 0x3afd7da4 libdispatch.dylib`_dispatch_root_queue_drain + 220
frame #8: 0x3afd7f8c libdispatch.dylib`_dispatch_worker_thread2 + 56
frame #9: 0x3b112dbe libsystem_pthread.dylib`_pthread_wqthread + 298
The stack trace for all threads are:
thread #1: tid = 0xa06fd, 0x3b099a8c libsystem_kernel.dylib`mach_msg_trap + 20, queue = 'com.apple.main-thread
frame #0: 0x3b099a8c libsystem_kernel.dylib`mach_msg_trap + 20
frame #1: 0x3b09988c libsystem_kernel.dylib`mach_msg + 48
frame #2: 0x3038a7ca CoreFoundation`__CFRunLoopServiceMachPort + 154
frame #3: 0x30388f36 CoreFoundation`__CFRunLoopRun + 854
frame #4: 0x302f3ce6 CoreFoundation`CFRunLoopRunSpecific + 522
frame #5: 0x302f3aca CoreFoundation`CFRunLoopRunInMode + 106
frame #6: 0x34fe1282 GraphicsServices`GSEventRunModal + 138
frame #7: 0x32b95a40 UIKit`UIApplicationMain + 1136
frame #8: 0x00075864 MyProduct`main(argc=1, argv=0x27d94d04) + 116 at main.m:16
thread #2: tid = 0xa070e, 0x3b09983c libsystem_kernel.dylib`kevent64 + 24, queue = 'com.apple.libdispatch-manager
frame #0: 0x3b09983c libsystem_kernel.dylib`kevent64 + 24
frame #1: 0x3afda224 libdispatch.dylib`_dispatch_mgr_invoke + 232
frame #2: 0x3afd9faa libdispatch.dylib`_dispatch_mgr_thread$VARIANT$mp + 38
thread #6: tid = 0xa0713, 0x3b099a8c libsystem_kernel.dylib`mach_msg_trap + 20, name = 'com.apple.NSURLConnectionLoader
frame #0: 0x3b099a8c libsystem_kernel.dylib`mach_msg_trap + 20
frame #1: 0x3b09988c libsystem_kernel.dylib`mach_msg + 48
frame #2: 0x3038a7ca CoreFoundation`__CFRunLoopServiceMachPort + 154
frame #3: 0x30388ef0 CoreFoundation`__CFRunLoopRun + 784
frame #4: 0x302f3ce6 CoreFoundation`CFRunLoopRunSpecific + 522
frame #5: 0x302f3aca CoreFoundation`CFRunLoopRunInMode + 106
frame #6: 0x30d2d496 Foundation`+[NSURLConnection(Loader) _resourceLoadLoop:] + 318
frame #7: 0x30da2e26 Foundation`__NSThread__main__ + 1062
frame #8: 0x3b114c1c libsystem_pthread.dylib`_pthread_body + 140
frame #9: 0x3b114b8e libsystem_pthread.dylib`_pthread_start + 102
thread #7: tid = 0xa0717, 0x3b0ac440 libsystem_kernel.dylib`select$DARWIN_EXTSN + 20, name = 'com.apple.CFSocket.private
frame #0: 0x3b0ac440 libsystem_kernel.dylib`select$DARWIN_EXTSN + 20
frame #1: 0x3038e68c CoreFoundation`__CFSocketManager + 484
frame #2: 0x3b114c1c libsystem_pthread.dylib`_pthread_body + 140
frame #3: 0x3b114b8e libsystem_pthread.dylib`_pthread_start + 102
thread #24: tid = 0xa0c20, 0x3b0abf38 libsystem_kernel.dylib`__psynch_cvwait + 24, queue = 'NSOperationQueue Serial Queue
frame #0: 0x3b0abf38 libsystem_kernel.dylib`__psynch_cvwait + 24
frame #1: 0x3b114228 libsystem_pthread.dylib`_pthread_cond_wait + 540
frame #2: 0x3b115004 libsystem_pthread.dylib`pthread_cond_wait + 40
frame #3: 0x30d8ed10 Foundation`-[__NSOperationInternal _waitUntilFinished:] + 84
frame #4: 0x30cfd7ce Foundation`-[NSBlockOperation main] + 130
frame #5: 0x30ced97a Foundation`-[__NSOperationInternal _start:] + 770
frame #6: 0x30d91b34 Foundation`__NSOQSchedule_f + 60
frame #7: 0x3afd7296 libdispatch.dylib`_dispatch_queue_drain$VARIANT$mp + 374
frame #8: 0x3afd709a libdispatch.dylib`_dispatch_queue_invoke$VARIANT$mp + 42
frame #9: 0x3afd7d14 libdispatch.dylib`_dispatch_root_queue_drain + 76
frame #10: 0x3afd7f8c libdispatch.dylib`_dispatch_worker_thread2 + 56
frame #11: 0x3b112dbe libsystem_pthread.dylib`_pthread_wqthread + 298
thread #25: tid = 0xa0c25, 0x3b112c7c libsystem_pthread.dylib`start_wqthread
frame #0: 0x3b112c7c libsystem_pthread.dylib`start_wqthread
thread #29: tid = 0xa0e39, 0x3b09983c libsystem_kernel.dylib`kevent64 + 24, queue = 'com.apple.NSURLSession-work
frame #0: 0x3b09983c libsystem_kernel.dylib`kevent64 + 24
frame #1: 0x3afd9ee6 libdispatch.dylib`_dispatch_kq_update + 190
frame #2: 0x3afd9e24 libdispatch.dylib`_dispatch_mgr_wakeup$VARIANT$mp + 44
frame #3: 0x3afd6762 libdispatch.dylib`_dispatch_wakeup$VARIANT$mp + 22
frame #4: 0x3afd6f40 libdispatch.dylib`_dispatch_queue_push_list_slow2 + 20
frame #5: 0x3afd7258 libdispatch.dylib`_dispatch_queue_drain$VARIANT$mp + 312
frame #6: 0x3afd709a libdispatch.dylib`_dispatch_queue_invoke$VARIANT$mp + 42
frame #7: 0x3afd7d14 libdispatch.dylib`_dispatch_root_queue_drain + 76
frame #8: 0x3afd7f8c libdispatch.dylib`_dispatch_worker_thread2 + 56
frame #9: 0x3b112dbe libsystem_pthread.dylib`_pthread_wqthread + 298
* thread #31: tid = 0xa0ed0, 0x302ed04a CoreFoundation`CFDictionaryGetValue + 10, queue = 'NSOperationQueue 0x15e32510, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x302ed04a CoreFoundation`CFDictionaryGetValue + 10
frame #1: 0x30d37438 Foundation`_NSSetIntValueAndNotify + 48
frame #2: 0x30041168 CFNetwork`__55-[__NSCFURLSession delegate_task:didCompleteWithError:]_block_invoke + 28
frame #3: 0x30cfd7ce Foundation`-[NSBlockOperation main] + 130
frame #4: 0x30ced97a Foundation`-[__NSOperationInternal _start:] + 770
frame #5: 0x30d91b34 Foundation`__NSOQSchedule_f + 60
frame #6: 0x3afd66de libdispatch.dylib`_dispatch_async_redirect_invoke$VARIANT$mp + 110
frame #7: 0x3afd7da4 libdispatch.dylib`_dispatch_root_queue_drain + 220
frame #8: 0x3afd7f8c libdispatch.dylib`_dispatch_worker_thread2 + 56
frame #9: 0x3b112dbe libsystem_pthread.dylib`_pthread_wqthread + 298
thread #32: tid = 0xa0f01, 0x3b112c7c libsystem_pthread.dylib`start_wqthread
frame #0: 0x3b112c7c libsystem_pthread.dylib`start_wqthread
The code that is crashing looks like this:
/* Simple polling - with a 1 sec delay between polls */
- (void) startPolling
{
NSLog(@"%@", @"Begin getStatusForZone");
[ws getStatusForZone:currentZone
success:^(NSURLSessionDataTask *task, NSDictionary *__autoreleasing zStatus) {
NSLog(@"%@", @"Complete getStatusForZone");
// Wait then poll again
if (isPolling) {
[self performSelector:@selector(startPolling) withObject:nil afterDelay:1.0];
}
}
failure:^(NSURLSessionDataTask *task, NSError *error)
{
NSLog(@"%@", @"Failed getStatusForZone");
// Wait then poll again
if (isPolling) {
[self performSelector:@selector(startPolling) withObject:nil afterDelay:1.0];
}
}];
}
I can provide more information as needed.
Any suggestions how I can determine the cause?
Thanks
Dkrinker
All 93 comments
AFNetworking doesn't show up anywhere in the stack trace. While not entirely definitive, it's a strong indicator that AFNetworking is not the problem. I will say that performSelector:withObject:afterDelay: can cause difficult-to-debug problems, but beyond that I can't really help you debug your application. Please try Stack Overflow or another forum.
mattt
on 11 Oct 2013
@Dkrinker , I am using AFNetworking 2.0.1 and have the same issue. Did you end up trying Stack Overflow, or solve this another way?
jordanwhitney
on 22 Oct 2013
Not yet. I think our next step is posting this as a support incident with Apple, as it looks like it maybe an issue in the completion handler for an NSURLSessionDataTask. I am curious whether your App is failing in the exact same spot? And whether you have had more success running on the iPad vs. the simulator? Also, what is your back end server that you are communicating with? Our back end is a ServiceStack based web service running on Windows.
Dkrinker
on 22 Oct 2013
Hi David,
Here are the backtraces for two separate runs of the app in which the crash is in CFDictionaryGetValue.
* thread #23: tid = 0x17a5f3, 0x2e0b98ea CoreFoundation`CFDictionaryGetValue + 10, queue = 'com.apple.NSURLSession-work, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x2e0b98ea CoreFoundation`CFDictionaryGetValue + 10
frame #1: 0x2eb055b4 Foundation`_NSSetIntValueAndNotify + 48
frame #2: 0x2ddabaf8 CFNetwork`-[__NSCFLocalSessionTask _task_onqueue_didFinish] + 368
frame #3: 0x2de07764 CFNetwork`__59-[__NSCFLocalSessionBridge task:didFinishLoadingWithError:]_block_invoke + 688
frame #4: 0x2de074b0 CFNetwork`-[__NSCFLocalSessionBridge task:didFinishLoadingWithError:] + 160
frame #5: 0x2de05ba8 CFNetwork`__64-[__NSCFLocalSessionBridge initWithConfiguration:session:queue:]_block_invoke + 48
frame #6: 0x2de23d94 CFNetwork`___ZNK24ClassicConnectionSession19_connection_didFailEP16_CFURLConnectionP9__CFError_block_invoke + 52
frame #7: 0x3896c102 libdispatch.dylib`_dispatch_call_block_and_release + 10
frame #8: 0x38970e76 libdispatch.dylib`_dispatch_queue_drain + 374
frame #9: 0x3896df9a libdispatch.dylib`_dispatch_queue_invoke + 42
frame #10: 0x38971750 libdispatch.dylib`_dispatch_root_queue_drain + 76
frame #11: 0x389719d0 libdispatch.dylib`_dispatch_worker_thread2 + 56
frame #12: 0x38a9bdfe libsystem_pthread.dylib`_pthread_wqthread + 298
* thread #87: tid = 0x62095, 0x302fb04a CoreFoundation`CFDictionaryGetValue + 10, queue = 'NSOperationQueue 0x14e4a9b0, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  frame #0: 0x302fb04a CoreFoundation`CFDictionaryGetValue + 10
  frame #1: 0x30d45438 Foundation`_NSSetIntValueAndNotify + 48
  frame #2: 0x3004f168 CFNetwork`__55-[__NSCFURLSession delegate_task:didCompleteWithError:]_block_invoke + 28
  frame #3: 0x30d0b7ce Foundation`-[NSBlockOperation main] + 130
  frame #4: 0x30cfb97a Foundation`-[__NSOperationInternal _start:] + 770
  frame #5: 0x30d9fb34 Foundation`__NSOQSchedule_f + 60
  frame #6: 0x3ab626de libdispatch.dylib`_dispatch_async_redirect_invoke$VARIANT$mp + 110
  frame #7: 0x3ab63da4 libdispatch.dylib`_dispatch_root_queue_drain + 220
  frame #8: 0x3ab63f8c libdispatch.dylib`_dispatch_worker_thread2 + 56
  frame #9: 0x3ac9edbe libsystem_pthread.dylib`_pthread_wqthread + 298
  frame #10: 0x3ac9ec84 libsystem_pthread.dylib`start_wqthread + 8
I am polling in a similar fashion, and my back end is written in Go (golang) using Ubuntu Server 12.04 LTS. Due to the nature of my app, it really only makes sense to run it on the device.
jordanwhitney
on 22 Oct 2013
Looks like exactly the same issue.
Dkrinker
on 22 Oct 2013
I am also experiencing this issue, not doing anything like performSelector in the callbacks - happens on both device (5S) and the simulator. I followed up on the Apple developer forums (https://devforums.apple.com/thread/210597) to see if any one from there can shed some light on this :)
Woody17
on 23 Oct 2013
I'm seeing the same thing shortly after upgrading to AFNetworking 2.0
(lldb) bt
* thread #14: tid = 0x1a6331, 0x02bb6c22 CoreFoundation`CFDictionaryGetValue + 18, queue = 'NSOperationQueue 0xde31840, stop reason = EXC_BAD_ACCESS (code=2, address=0x0)
frame #0: 0x02bb6c22 CoreFoundation`CFDictionaryGetValue + 18
frame #1: 0x0201f570 Foundation`_NSSetIntValueAndNotify + 74
frame #2: 0x042e5efc CFNetwork`__55-[__NSCFURLSession delegate_task:didCompleteWithError:]_block_invoke + 46
frame #3: 0x02023b85 Foundation`-[NSBlockOperation main] + 88
frame #4: 0x0207ca69 Foundation`-[__NSOperationInternal _start:] + 671
frame #5: 0x01ff9798 Foundation`-[NSOperation start] + 83
frame #6: 0x0207ed34 Foundation`__NSOQSchedule_f + 62
frame #7: 0x031424b0 libdispatch.dylib`_dispatch_client_callout + 14
frame #8: 0x0312f034 libdispatch.dylib`_dispatch_async_redirect_invoke + 202
frame #9: 0x031424b0 libdispatch.dylib`_dispatch_client_callout + 14
frame #10: 0x03130ef1 libdispatch.dylib`_dispatch_root_queue_drain + 287
frame #11: 0x0313113d libdispatch.dylib`_dispatch_worker_thread2 + 39
frame #12: 0x0353fe72 libsystem_c.dylib`_pthread_wqthread + 441
naughtont
on 28 Oct 2013
@naughtont Can you explain what type of requests you are making, i.e. if you are polling, or if this is due to a single request?
jordanwhitney
on 28 Oct 2013
This happens rarely during unit testing which only does one request at a time. It also happens during app launch which does multiple concurrent requests.
naughtont
on 29 Oct 2013
Same here. More info: http://crashes.to/s/fc3b8923c93
tomislav
on 2 Nov 2013
Seeing this all the time as well.
hjaltij
on 5 Nov 2013
Some discussion here:
https://devforums.apple.com/message/912794#912794
hjaltij
on 5 Nov 2013
@mattt Would you consider opening this again?
Seeing this from time to time after I switched to AFNetworking 2.0 and I'm not doing anything specific like the OP.
Also there's an interesting discussion on the Apple forum that I linked to above. Especially this answer:
https://devforums.apple.com/message/914379#914379
Cheers!
hjaltij
on 12 Nov 2013
I noticed [AFURLSessionManager observeValueForKeyPath:ofObject:change:context:] was being called on a background thread. I tried then calling [object removeObserver:self forKeyPath:@"state" context:AFTaskStateChangedContext] on the main thread, but still saw this crash. I commented out all the calls to:
[dataTask addObserver:self forKeyPath:@"state" options:NSKeyValueObservingOptionOld|NSKeyValueObservingOptionNew context:AFTaskStateChangedContext]
And I no longer see this crash. The only casualty so far seems to be the spinner from the AFNetworkActivityIndicatorManager.
KVO observing the state property on a NSURLSessionDataTask may be a bad idea.
naughtont
on 14 Nov 2013
I can confirm that I'm no longer seeing crashes after this change.
hjaltij
on 15 Nov 2013
Me too.
Dkrinker
on 15 Nov 2013
That's all very interesting. Thanks for posting details, @naughtont.
It's a shame that NSURLSessionTask objects have an implementation of KVO that is prone to crashing.
Unfortunately, state observation in the service of global notifications and the network activity indicator is an essential feature, and removing it is non-negotiable for a crash that doesn't appear to be manifesting itself consistently.
53673f1 attempts to work around the problem by moving removeObserver to the delegate method, where the threading situation is hopefully a little more reliable. dispatch-ing to main for removal here might be another recourse here.
Let me know if 53673f1 addresses this problem at all for you. Like I said, the notification feature is non-negotiable, but I would of course be open to hearing alternative proposals for how the feature might be implemented without KVO.
mattt
on 18 Nov 2013
Yes that fixes the problem. My unit tests are passing without issue in 2.0.3. Thanks! Have you considered getting rid of the exception handler with something like the following?
- @try {
+ if ([self.observees containsObject:task]) {
[task removeObserver:self forKeyPath:@"state" context:AFTaskStateChangedContext];
- } @catch (NSException *exception) {}
+ [self.observees removeObject:task];
+ }
I'm still seeing this crash with the latest master. Here is a crash example:
Thread 10: Crashed: AFNetworking 0 Foundation 0x2ff17446 __NSOQSchedule + 325 1 Foundation 0x2ff1733d __NSOQSchedule + 60 2 Foundation 0x2fe76ec7 +[__NSOperationInternal _observeValueForKeyPath:ofObject:changeKind:oldValue:newValue:indexes:context:] + 966 3 Foundation 0x2fe76a0b NSKeyValueNotifyObserver + 90 4 Foundation 0x2fe76765 NSKeyValueDidChange + 344 5 Foundation 0x2fe62d65 -[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] + 88 6 Kicksend 0x002975d5 -[AFURLConnectionOperation setState:] (AFURLConnectionOperation.m:329) 7 Kicksend 0x00298b8f -[AFURLConnectionOperation finish] (AFURLConnectionOperation.m:453) 8 Kicksend 0x0029b43f -[AFURLConnectionOperation connection:didFailWithError:] (AFURLConnectionOperation.m:672) 9 Kicksend 0x00299269 -[AFURLConnectionOperation cancelConnection] (AFURLConnectionOperation.m:484) 10 Foundation 0x2ff2ae4b __NSThreadPerformPerform + 386 11 CoreFoundation 0x2f511f1f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14 12 CoreFoundation 0x2f5113e7 __CFRunLoopDoSources0 + 206 13 CoreFoundation 0x2f50fbd7 __CFRunLoopRun + 630 14 CoreFoundation 0x2f47a471 CFRunLoopRunSpecific + 524 15 CoreFoundation 0x2f47a253 CFRunLoopRunInMode + 106 16 Foundation 0x2fe68697 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 254 17 Foundation 0x2feb94d9 -[NSRunLoop(NSRunLoop) run] + 80 18 Kicksend 0x00295b87 +[AFURLConnectionOperation networkRequestThreadEntryPoint:] (AFURLConnectionOperation.m:158) 19 Foundation 0x2ff2ac37 __NSThread__main__ + 1062 20 libsystem_pthread.dylib 0x39ebdc5d _pthread_body + 140 21 libsystem_pthread.dylib 0x39ebdbcf _pthread_start + 102
Reflejo
on 9 Dec 2013
@mattt: This does not appear to be fixed - in a release today, this is our most common crash. One thing I noticed in perusing the code is that the [AFURLConnectionOperation finish] method is the only place where we set the state of the operation without locking on self.lock. Is this an oversight or is this on purpose for some reason? If it is on purpose, perhaps a comment as to why might be in order?
iragsdale
on 11 Feb 2014
Just to keep anyone paying attention up to date, wrapping [self.lock lock] & [self.lock unlock] around self.state = AFOperationFinishedState doesn't seem to have had any adverse effects in my testing, so we're probably going to release a new build with those changes soon. If that resolves the issue, I'll submit a patch & update the ticket.
iragsdale
on 11 Feb 2014
@iragsdale 259c736 added this patch to master. Notably, this change is not related to the reported issue.
mattt
on 11 Feb 2014
@mattt Just wanted to chime in. We just pushed a new release (iOS 7 only) in which we moved to AFNetworking (2.2.1) for most everything. Currently this is one of our biggest crashes and has accounted for ~6500 crashes in the last 24 hours. We're not using the built in activity indicators so as a hotfix we're planning on just disabling the KVO on the state property. I'll report back on whether this does indeed solve the crashes we're seeing and plan on looking into a more elegant long term solution.
lordkev
on 2 Apr 2014
Having the same combination of iOS7 only / AFNetworking 2.2.1 as lordkev, i can confirm that this crash is still happening with a very high frequency. @lordkev What kind of short term solution have you fall back to? Thanks
uros-gardasevic
on 17 Apr 2014
@uros-gardasevic For now I simply commented out the KVO around the state property. It does sacrifice the functionality of the AFNetworkActivityIndicatorManager, but we weren't using it anyway. Here's the relevant commit on my fork:
https://github.com/lordkev/AFNetworking/commit/7507ad0c935a48970d2a0a4aeeac7f9e852524cf
lordkev
on 17 Apr 2014
Oh yeah, and it has indeed solved the crashes. We're no longer seeing them.
lordkev
on 17 Apr 2014
It looks like I'm running into the same problem:
Thread : Crashed: com.apple.NSURLSession-work
0 CoreFoundation 0x2e0ecf8a CFDictionaryGetValue + 9
1 Foundation 0x2eb38299 _NSSetIntValueAndNotify + 48
2 Foundation 0x2eb38299 _NSSetIntValueAndNotify + 48
3 CFNetwork 0x2dddf73f -[__NSCFLocalSessionTask _task_onqueue_didFinish] + 366
4 CFNetwork 0x2de3b501 __59-[__NSCFLocalSessionBridge task:didFinishLoadingWithError:]_block_invoke + 688
5 CFNetwork 0x2de3b24b -[__NSCFLocalSessionBridge task:didFinishLoadingWithError:] + 158
6 CFNetwork 0x2de39945 __64-[__NSCFLocalSessionBridge initWithConfiguration:session:queue:]_block_invoke + 48
7 CFNetwork 0x2de57ac9 ___ZNK24ClassicConnectionSession28_connection_didFinishLoadingEP16_CFURLConnection_block_invoke + 40
8 libdispatch.dylib 0x38d74d1b _dispatch_call_block_and_release + 10
9 libdispatch.dylib 0x38d7b273 _dispatch_queue_drain$VARIANT$mp + 374
10 libdispatch.dylib 0x38d7b06b _dispatch_queue_invoke$VARIANT$mp + 42
11 libdispatch.dylib 0x38d7bce1 _dispatch_root_queue_drain + 76
12 libdispatch.dylib 0x38d7bf59 _dispatch_worker_thread2 + 56
13 libsystem_pthread.dylib 0x38eb6dbf _pthread_wqthread + 298
It looks identical to the one reported by @jordanwhitney
I have encountered this crash only once, I'm using AFNetworking 2.2.3. I will try out 2.2.4.
yvbeek
on 14 May 2014
This is our most common crash by far too. Going to try @lordkev's solution for our next update.
PadraigK
on 18 May 2014
I plan on bringing up this NSURLSessionTask KVO crash in the WWDC labs - will report back.
lordkev
on 21 May 2014
@lordkev Let me know when you go! Would love to stop by and chat about it with Apple (and say hello as well) :beers:
kcharwood
on 21 May 2014
@kcharwood Sounds good! I'll be there with @Cform too, so it can be a big ol' reunion. :)
lordkev
on 22 May 2014
After a release with the hot fix and an example that manages to crash the application within 15 seconds, i can confirm that the crash is 100% reproducible. Indeed, in my case this is happening due to high frequency of subsequent requests. Thanks again for narrowing down the source of the problem.
uros-gardasevic
on 23 May 2014
@uros-gardasevic Can you post the example project? I'd love to look into it further.
PadraigK
on 25 May 2014
I'm experiencing this exact issue just when I make a multipart request. 100% reproducible, just happens when I do the request from iOS 8 simulator, iOS 8 base SDK, iPhone 5s simulator. Synthesising streamStatus and streamError solves the problem for me.
alvaromb
on 15 Jun 2014
@alvaromb that was a different issue caused by a bug in one of the last versions of AFNetworking. Upgrade to the latest version and it is resolved.
yvbeek
on 15 Jun 2014
@Zyphrax can you point me to the version that was causing this issue? Was only iOS 8 or was affecting previous versions also?
alvaromb
on 15 Jun 2014
@alvaromb check out https://github.com/AFNetworking/AFNetworking/blob/master/CHANGES
It was a bug in 2.3.0 affecting all versions, resolved in 2.3.1
yvbeek
on 15 Jun 2014
Thanks @Zyphrax!!! Some customers were complaining about app hangs when uploading pictures, but it seems that it was due to bad network connection, because we're running AFNetworking 2.2.4, no 2.3 yet.
alvaromb
on 16 Jun 2014
Forgot to update this after going to a Networking lab @ WWDC. I spoke with an Apple engineer and he looked up the Radar that the employee in the dev forums linked to. The bug was actually in KVO itself, not in NSURLSessionTask or a related class. There was an example project attached to the Radar demonstrating the issue. After running it on Mavericks and verifying it was still happening, he ran it on Yosemite and it appeared to be solved. He also stated that iOS 8 and OS X should now be sharing the same KVO code, so if it's fixed on one it should be fixed on the other as well.
It would be interesting to see if @uros-gardasevic's example project still causes issues on iOS 8 / OS X Yosemite.
lordkev
on 16 Jun 2014
Yes, let me just dig it up from some temp folder, and i'll share it with you guys. I'm curious as well.
uros-gardasevic
on 16 Jun 2014
We are also running in to this issue currently. We are making use of the AFNetworkActivityIndicatorManager.
One thing I've noticed is that every single crash has happened on a 64-bit device.
cooksimo
on 24 Jun 2014
We're also running into this issue. We can apply the workaround suggested by @lordkev but this affects AFNetworkActivityIndicatorManager which we are relying upon.
In the end of Apple's devforuns link ( https://devforums.apple.com/thread/210597 ) there is a comment by Apple's Quinn "The Eskimo!" saying something like this:
I passed some info along to the AFNetworking folks and hopefully they'll be able to implement a reliable workaround.
@mattt Do you have that reliable workaround with you, and if so, can you share it with us?
Thanks.
cabeca
on 21 Jul 2014
I am also seeing this consistently, but only on 64bit devices. Is there a final fix suggested in AFNetworking for the KVO on NSURLSessionTask issue? @mattt I suggest reopening this issue for further investigation...
jmkk
on 23 Jul 2014
@jmkk you find a clean solution to this yet besides commenting out the problem kvo lines?
rromanchuk
on 12 Sep 2014
@rromanchuk So far this is the only fix that works.
jmkk
on 12 Sep 2014
@jmkk do you know if anyone confirmed this kvo issue on ios8 yet?
rromanchuk
on 12 Sep 2014
@uros-gardasevic Did you confirm that this is now fixed on iOS 8?
sethfri
on 14 Sep 2014
To be honest, after confirming that this workaround has cleaned our crash dashboard, we decreased the priority for this issue. I did extract the part of our software into the separate project where i could easily crash the app in a matter of minutes. Unfortunately, i can not find it anymore. In case i lay my hands on it, i promise to share that piece of code.
uros-gardasevic
on 14 Sep 2014
@naughtont did https://github.com/AFNetworking/AFNetworking/issues/1477#issuecomment-28735565 ever work for you?
rromanchuk
on 15 Sep 2014
I'm seeing crash reports from my iOS 8 users that look just like this using AFNetworking 2.3.1.
docgravel
on 20 Sep 2014
We're also seeing this crash for both iOS 7 and iOS 8 users, using both AFNetworking 2.2.1 and 2.4.1, and running both 32 and 64-bit devices. (The stack trace is slightly different for 32 and 64, referencing _NSSetIntValueAndNotify on 32-bit devices and _NSSetLongLongValueAndNotify on 64-bit devices.)
According to our Crashlytics numbers, this crash seems to occur about 10x more often in AFNetworking 2.4.1 than in 2.2.1. After some digging, I suspect that #2153 is to blame, but I have no real data to back that up.
tangphillip
on 22 Sep 2014
This is the number one crash in the latest version of our app, which requires iOS 8 and uses AFNetworking 2.3.1. We're seeing this crash roughly a hundred times per day and it occurs on both 32 and 64 bit devices. It generally doesn't happen to the same user more than once. We were not seeing this crash while using AFNetworking 1.x.
We're using AFNetworkActivityIndicatorManager, so disabling the @"state" observation is not an ideal solution, but it looks like we may have to go that route temporarily.
Can this bug please be re-opened (or a new one created) until we find a solution?
jmarr
on 24 Sep 2014
@jmarr @mattt this definitely needs to be reopened, regardless of 'fault' KVO bug or not, AFNetworking (we) should find a workaround, or completely remove support for AFNetworkActivityIndicatorManager and remove the broken KVO. Currently "out of the box" AFNetworking is also our #1 crash. Forking and commenting out a line isn't really a solution, and the bug still exists in ios8 so we can't really wait for Apple to fix this for us.
At the very least, we should update the readme and be upfront that AFNetworking's implementation of NSURLSession is _not_ production ready.
rromanchuk
on 26 Sep 2014
We experienced the same problem and had to use a fork with the @"state" fix.
Would be great to have this bug reopened.
eKaiju
on 26 Sep 2014
We're in the same boat as @jmarr; number one crash in the app and we can't use the @"state" observation patch without breaking AFNetworkActivityIndicatorManager. Would really like to see this fixed.
msanders
on 30 Sep 2014
@msanders it might be due to invalid response i mean invalid json coming in the response that will lead to internal crash in afnetworking.
Means It happend for me when i have used
AFHTTPRequestOperation *op = [[AFHTTPRequestOperation alloc] initWithRequest:request];
op.responseSerializer = [AFJSONResponseSerializer serializer];
And if invalid json will come in respopnse then it will crash and give bad access.
And i solved this issue by removing
op.responseSerializer = [AFJSONResponseSerializer serializer];
and then check the response that i will get in the Success block with
NSDictionary *responseDic = [NSJSONSerialization JSONObjectWithData:responseObject options:kNilOptions error:&parsingError];
if (!responseDic) {
// NSLog(@"parsingError == %@",[parsingError localizedDescription]);
]
}else{
// Success
}
Let me know.
saurabhiphone
on 30 Sep 2014
So like other people here I did my own fork and removed the KVO lines. I hope it get fixed soon, if it's an Apple issue it might worth the try on iOS 8.1 beta.
Also, any of you have a 100% reproducible crash ? Mine are just random, I get some crash report with it, but I can't reproduce it.
Dimillian
on 7 Oct 2014
Can anyone confirm if this is fixed in the 2.4.1 release? Currently our number one crash and submitting a hotfix tonight. We've implemented the fix that many of you have done in your own forks.
kristianbauer
on 22 Oct 2014
@kristianbauer This is definitively not fixed in 2.4.1. It's our #1 crash, and we're running AFNetworking 2.4.1.
tangphillip
on 22 Oct 2014
still seeing this in iOS 8.1, I agree this needs to be re-opened for a work around or a fix please
ahashp
on 28 Oct 2014
1 bug in our Crashlytics page as well, also waiting for a fix please.
maciekish
on 3 Nov 2014
As others already said - number one crash in our app, appears even on 8.1 with AFNetworking 2.4.1.
srihards
on 5 Nov 2014
same here iOS 8.0.2 AFNetworking 2.4.1
vickieduong
on 6 Nov 2014
Hoping the crash data for this issue in my app may help. This data comes from an app built using AFNetworking 2.3.1. The crash is happening exclusively on iOS 8 and is, like many others, my #1 crash.
I'm in a situation where I think I can remove the [task addObserver:self code in AFURLSessionManager as suggested by @naughtont - the other proposed fixes make me nervous. Is there anything making its way to Master for this?
bdalziel
on 6 Nov 2014
I solved this problem in our app by removing the KVO call and replacing its functionality by swizzling -[NSURLSessionTask suspend] and -[NSURLSessionTask resume]. The code is on my fork of AFNetworking: https://github.com/tangphillip/AFNetworking/
I've put the fix live in our production app, with 500,000 devices updated to the swizzled version. So far, our app has some crashes, but zero CFDictionaryGetValue crashes.
Our app does not suspend network calls or make background uploads or downloads. Therefore, this fix is not 100% tested. If your app does any of those things, TEST IT BEFORE SHIPPING THIS SWIZZLE.
I don't really expect this to be merged into AFNetworking master, but I've pull requested the fix here anyway: #2411
tangphillip
on 6 Nov 2014
We were able to reproduce the crash quite easily and also ended up commenting out the same KVO lines. I don't quite understand why this issue is still marked as Closed.
ianolito
on 11 Nov 2014
@ianolito Do you have specific steps to reproduce the issue? We've still never been able to crash the app on purpose.
tangphillip
on 11 Nov 2014
Also experiencing this issue, have not tried any fixes yet. Will report back.
garfbargle
on 14 Nov 2014
2411 was merged today. This issue should be resolved in the next release of AFNetworking.
tangphillip
on 14 Nov 2014
Thanks for the update @tangphillip :)
garfbargle
on 14 Nov 2014
Thanks @tangphillip that's great news!
I don't have specific steps but we can reproduce it reliably by letting our app download continuously for a few minutes. I'll make sure to test again now that your fix is merged in.
ianolito
on 14 Nov 2014
Yes, thank you very much @tangphillip for the fix. Very glad to see that it got merged. I just updated our app to start using the head of the AFNetworking master branch so we can start testing it right away.
As with many others on this thread, this CFDictionaryGetValue crash (all 4 flavors) is at the top of our Crashlytics dashboard.
medington
on 15 Nov 2014
One more thanks to @tangphillip. I just pulled the head version into our project but it seems the workaround has broken the status bar AFNetworkActivityIndicatorManager on iOS 7. Seems to work fine on iOS 8 though.
erikjalevik
on 21 Nov 2014
@erikjalevik Oh no! That's not good.
I filed a bug about your issue and opened a pull request that fixes it. Unfortunately, it may not be merged, because the fix entails swizzling a method on __NSCFLocalSessionTask, which is a private class. It's possible to do so without ever mentioning the class name or calling any private methods, but...it's not a good way to do things.
tangphillip
on 30 Nov 2014
An update following the crashlytics stats I posted in https://github.com/AFNetworking/AFNetworking/issues/1477#issuecomment-62047785 - this issue is no longer the standout crash leader, and is tracking alongside other similarly unreliable sporadic crashes. Thanks for the fix @tangphillip
bdalziel
on 1 Dec 2014
Spent the entire day hunting down what turned out to be a years-old missing retain in the guts of KVO. Tell me again how ARC isn't useful? 😛
Let’s cross fingers that this crasher will be fixed in a future version of iOS and OS X…
_Edit:_
Looks like the workaround may live longer:
@0xced highly unlikely. I’m 99% certain no existing code triggered the bug.
0xced
on 19 Feb 2015
still having this issue with 2.5.2 on ios7
Sega-Zero
on 30 Mar 2015
@Sega-Zero Could you please post your crash log?
tangphillip
on 31 Mar 2015
@tangphillip it happened randomly, couldn't catch it again, but i was debugging an app when the crash occurs.
It was crashed inside [AFURLSessionManager taskDidResume:] at line 414 and I think that's because the task wasn't alive at this point, because i called [AFHTTPSessionManager invalidateSessionCancelingTasks:NO] method inside success handler
Sega-Zero
on 31 Mar 2015
@Sega-Zero Your crash is likely unrelated to the one I fixed here—this crash's stack trace was deep inside Apple code. You almost certainly have a different issue, perhaps for the reason you said?
tangphillip
on 31 Mar 2015
well, it was certainly because of swizzled method af_resume. it posts a notification and the object (as of in my case) can be dealloced by the time when a notification will be sent to an observer.
i turned off state observing - and no crashes at all
Sega-Zero
on 31 Mar 2015
Did we ever log a bug with apple on this? I couldnt find on bugreport.apple.com and i still see this issue.
rafe-g
on 12 Oct 2016
Recently I got this report. Is this same issue?
#3. Crashed: com.apple.NSURLConnectionLoader
0 CoreFoundation 0x185a91898 CFDictionaryGetValue + 56
1 CFNetwork 0x18550bdec SocketStream::copyProperty(void const*, __CFString const*) + 152
2 CoreFoundation 0x185b79048 CFReadStreamCopyProperty + 168
3 CFNetwork 0x18555b78c SPDYConnection::isCellular() + 36
4 CFNetwork 0x18555b724 SPDYConnection::shouldIdleClose(double, double) + 60
5 CFNetwork 0x18556f630 ___ZN24SPDYConnectionCacheEntry15shouldIdleCloseEdd_block_invoke + 32
6 CoreFoundation 0x185a98bfc CFArrayApplyFunction + 68
7 CFNetwork 0x18556f5e8 SPDYConnectionCacheEntry::shouldIdleClose(double, double) + 140
8 CFNetwork 0x1855eb6e4 SPDYConnectionCache::_onqueue_purgeIdleConnections(bool) + 276
9 CFNetwork 0x18551afa4 RunloopBlockContext::_invoke_block(void const*, void*) + 76
10 CoreFoundation 0x185a98bfc CFArrayApplyFunction + 68
11 CFNetwork 0x18551ae50 RunloopBlockContext::perform() + 136
12 CFNetwork 0x18551ad04 MultiplexerSource::perform() + 312
13 CFNetwork 0x18551ab30 MultiplexerSource::_perform(void*) + 68
14 CoreFoundation 0x185b6e0e8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
15 CoreFoundation 0x185b6d444 __CFRunLoopDoSources0 + 448
16 CoreFoundation 0x185b6b43c __CFRunLoopRun + 712
17 CoreFoundation 0x185a991f4 CFRunLoopRunSpecific + 396
18 CFNetwork 0x18559d6a4 +[NSURLConnection(Loader) _resourceLoadLoop:] + 440
19 Foundation 0x186a85c0c __NSThread__main__ + 1072
20 libsystem_pthread.dylib 0x196b1fe80 _pthread_body + 164
21 libsystem_pthread.dylib 0x196b1fddc _pthread_body + 158
22 libsystem_pthread.dylib 0x196b1cfb0 thread_start + 4
c4free
on 2 Nov 2016
I don’t think so, but it has been a while since I looked at this issue.
David Krinker
From: carrot [email protected]
Reply-To: AFNetworking/AFNetworking [email protected]
Date: Wednesday, November 2, 2016 at 12:43 AM
To: AFNetworking/AFNetworking [email protected]
Cc: David Krinker [email protected], Mention [email protected]
Subject: Re: [AFNetworking/AFNetworking] EXC_BAD_ACCESS exception (#1477)
Recently I got this report. Is this same issue?
3. Crashed: com.apple.NSURLConnectionLoader
0 CoreFoundation 0x185a91898 CFDictionaryGetValue + 56
1 CFNetwork 0x18550bdec SocketStream::copyProperty(void const_, __CFString const_) + 152
2 CoreFoundation 0x185b79048 CFReadStreamCopyProperty + 168
3 CFNetwork 0x18555b78c SPDYConnection::isCellular() + 36
4 CFNetwork 0x18555b724 SPDYConnection::shouldIdleClose(double, double) + 60
5 CFNetwork 0x18556f630 _ZN24SPDYConnectionCacheEntry15shouldIdleCloseEdd_block_invoke + 32
6 CoreFoundation 0x185a98bfc CFArrayApplyFunction + 68
7 CFNetwork 0x18556f5e8 SPDYConnectionCacheEntry::shouldIdleClose(double, double) + 140
8 CFNetwork 0x1855eb6e4 SPDYConnectionCache::_onqueue_purgeIdleConnections(bool) + 276
9 CFNetwork 0x18551afa4 RunloopBlockContext::_invoke_block(void const_, void_) + 76
10 CoreFoundation 0x185a98bfc CFArrayApplyFunction + 68
11 CFNetwork 0x18551ae50 RunloopBlockContext::perform() + 136
12 CFNetwork 0x18551ad04 MultiplexerSource::perform() + 312
13 CFNetwork 0x18551ab30 MultiplexerSource::_perform(void*) + 68
14 CoreFoundation 0x185b6e0e8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 24
15 CoreFoundation 0x185b6d444 CFRunLoopDoSources0 + 448
16 CoreFoundation 0x185b6b43c __CFRunLoopRun + 712
17 CoreFoundation 0x185a991f4 CFRunLoopRunSpecific + 396
18 CFNetwork 0x18559d6a4 +[NSURLConnection(Loader) _resourceLoadLoop:] + 440
19 Foundation 0x186a85c0c __NSThread__main + 1072
20 libsystem_pthread.dylib 0x196b1fe80 _pthread_body + 164
21 libsystem_pthread.dylib 0x196b1fddc _pthread_body + 158
22 libsystem_pthread.dylib 0x196b1cfb0 thread_start + 4
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Dkrinker
on 2 Nov 2016
This is our top crash too and but funnily only started happening as soon as we started supporting iOS 10. As of now 100% of the crashes are on iOS 10. The call stack is pretty much the same:
@mattt any clue if some iOS 10 change may have re-introduced this issue?
Crashed: com.apple.NSURLSession-work
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000003
Crashed: com.apple.NSURLSession-work
0 CoreFoundation 0x1918e30bc CFDictionaryGetValue + 44
1 Foundation 0x1924ea5d0 _NSSetLongLongValueAndNotify + 72
2 CFNetwork 0x19202b168 <redacted> + 428
3 CFNetwork 0x19202d8bc <redacted> + 68
4 CFNetwork 0x1920e1628 <redacted> + 136
5 CFNetwork 0x1920e1594 <redacted> + 88
6 libdispatch.dylib 0x19089a1fc _dispatch_call_block_and_release + 24
7 libdispatch.dylib 0x19089a1bc _dispatch_client_callout + 16
8 libdispatch.dylib 0x1908a83dc _dispatch_queue_serial_drain + 928
9 libdispatch.dylib 0x19089d9a4 _dispatch_queue_invoke + 652
10 libdispatch.dylib 0x1908aa34c _dispatch_root_queue_drain + 572
11 libdispatch.dylib 0x1908aa0ac _dispatch_worker_thread3 + 124
12 libsystem_pthread.dylib 0x190aa32a0 _pthread_wqthread + 1288
13 libsystem_pthread.dylib 0x190aa2d8c start_wqthread + 4
sanyam-coursera
on 15 Feb 2017
@mattt We also get same crashes here I am adding two different crash caused in iOS 10
and mostly 10.2 and later
Crashed: com.apple.CFNetwork.Connection
0 CFNetwork 0x18af25940
1 CFNetwork 0x18af44d8c
2 CFNetwork 0x18b041304
3 CFNetwork 0x18b062e0c
4 CFNetwork 0x18b062b3c
5 CFNetwork 0x18b00d728
6 CFNetwork 0x18b00cf7c
7 libdispatch.dylib 0x1896da1fc _dispatch_call_block_and_release + 24
8 libdispatch.dylib 0x1896da1bc _dispatch_client_callout + 16
9 libdispatch.dylib 0x1896e83dc _dispatch_queue_serial_drain + 928
10 libdispatch.dylib 0x1896dd9a4 _dispatch_queue_invoke + 652
11 libdispatch.dylib 0x1896ea34c _dispatch_root_queue_drain + 572
12 libdispatch.dylib 0x1896ea0ac _dispatch_worker_thread3 + 124
13 libsystem_pthread.dylib 0x1898e32a0 _pthread_wqthread + 1288
14 libsystem_pthread.dylib 0x1898e2d8c start_wqthread + 4
another crash is
Crashed: com.apple.NSURLConnectionLoader
0 libsystem_platform.dylib 0x1920150d4 __bzero + 36
1 libz.1.dylib 0x1922a0824 (null) + 60
2 libz.1.dylib 0x1922a0824 (null) + 60
3 libz.1.dylib 0x19229e404 (null) + 5920
4 libz.1.dylib 0x19229e1e4 inflate + 5376
5 CFNetwork 0x193641cd8
6 CFNetwork 0x193641a28
7 CFNetwork 0x1936c973c
8 CFNetwork 0x1936c98dc
9 libdispatch.dylib 0x191e12a98 _dispatch_data_apply + 128
10 libdispatch.dylib 0x191e175e4 dispatch_data_apply + 40
11 CFNetwork 0x1936c35c8
12 CFNetwork 0x1936c2bbc
13 CFNetwork 0x1937a8410
14 libdispatch.dylib 0x191e121bc _dispatch_client_callout + 16
15 libdispatch.dylib 0x191e1dab0 _dispatch_block_invoke_direct + 376
16 CFNetwork 0x1937c2598
17 CoreFoundation 0x192e61c18 CFArrayApplyFunction + 68
18 CFNetwork 0x1937c247c
19 CFNetwork 0x1937c37a4
20 CFNetwork 0x1937c3510
21 CoreFoundation 0x192f36b5c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
22 CoreFoundation 0x192f364a4 __CFRunLoopDoSources0 + 524
23 CoreFoundation 0x192f340a4 __CFRunLoopRun + 804
24 CoreFoundation 0x192e622b8 CFRunLoopRunSpecific + 444
25 CFNetwork 0x193667a70
26 Foundation 0x193a9ce68 __NSThread__start__ + 1024
27 libsystem_pthread.dylib 0x19201d850
28 libsystem_pthread.dylib 0x19201d760 _pthread_start + 282
29 libsystem_pthread.dylib 0x19201ad94 thread_start + 4
sagariosdev
on 21 Feb 2017
@kcharwood are you managing the releases now? I see a bunch of potential KVO fixes on master which haven't been included in any release yet, wondering if you guys are planning another release?
sanyam-coursera
on 21 Feb 2017
@sanyam-coursera Which version of AFNetworking this happen to you? 2.3.1 ?
shahaf
on 19 Jul 2017
@shahaf we were able to fix the issue, found a reference in our code base that was observing 'status'. Removing that fixed our crashes.
sanyam-coursera
on 19 Jul 2017
By reading up comments, I known that the bug about "NSURLSession-work -> CFDictionaryGetValue" have fixed by removing observe 'status'.
And I check my local AFN (version : 2.6.3) code that the observe 'status' have removed, but my app have crash as same log.
The same crash log : "NSURLSession-work -> CFDictionaryGetValue".
AFN version：2.6.3
Thread 24 name: Dispatch queue: com.apple.NSURLSession-work
Thread 24 Crashed:
0 CFNetwork coreSchedulingSetHash(void const*) + 0
1 CoreFoundation CFBasicHashFindBucket + 164
2 CoreFoundation CFDictionaryGetValue + 164
3 CFNetwork RunLoopMultiplexer::signal(CoreSchedulingSet const*, MultiplexerClient*) + 52
4 CFNetwork RunloopBlockContext::addBlockAndSignal(void () block_pointer) + 180
5 CFNetwork URLConnectionClient_Classic::_withDelegateAsync(char const*, void (_CFURLConnection*, CFURLConnectionClientCurrent_VMax const*) block_pointer) + 336
6 CFNetwork URLConnectionClient_Classic::_delegate_willSendRequestForAuthenticationChallenge(_CFURLAuthChallenge*) + 152
7 CFNetwork ___ZN19URLConnectionLoader41protocolDidReceiveAuthenticationChallengeEP19_CFURLAuthChallenge_block_invoke_3 + 44
8 CFNetwork ___ZN20ClassicURLConnection21withLoaderClientAsyncEU13block_pointerFvP21LoaderClientInterfaceE_block_invoke + 28
9 CFNetwork ___ZNK25URLConnectionInstanceData18withWorkQueueAsyncEU13block_pointerFvvE_block_invoke + 28
10 libdispatch.dylib _dispatch_call_block_and_release + 24
11 libdispatch.dylib _dispatch_client_callout + 16
12 libdispatch.dylib _dispatch_queue_serial_drain + 928
13 libdispatch.dylib _dispatch_queue_invoke + 884
14 libdispatch.dylib _dispatch_root_queue_drain + 540
15 libdispatch.dylib _dispatch_worker_thread3 + 124
16 libsystem_pthread.dylib _pthread_wqthread + 1096
wangdetong
on 28 Sep 2017
I'm getting the exact same problem.
matteogobbi
on 31 Oct 2020
I'm getting the exact same problem.
We've been seeing this recently with some network analytics frameworks, especially Firebase Performance. You either need to remove the framework or update to a newer version, as they may have fixed the issue.
jshier
on 31 Oct 2020
Interesting. Thank you for your answer. I removed Firebase/Performance and the problem is solved.
Thanks a lot.
matteogobbi
on 31 Oct 2020
Related issues
appcelerate
·
5Comments
jhongui
·
5Comments
hdoria
·
3Comments
Joxy
·
3Comments
474404603
·
5Comments
Most helpful comment
We've been seeing this recently with some network analytics frameworks, especially Firebase Performance. You either need to remove the framework or update to a newer version, as they may have fixed the issue.