Crash on _GLOBAL__I_a while performing network calls

Hi guys,

We have this crash, where we have no information at the app level of what could be going on. All we know is that the user crashes when performing network calls, and we are not able to recreate it because there is no pattern between each crash, it can happen with any network call at any time. This particular stacktrace, belongs to iOS9 devices, but we have more, slightly different, affecting iOS8 devices.


The crash happens on the main thread and the suspected line where the crash happens is the _GLOBAL__I_a line(line number 6 for this stacktrace). I believe it would be good for you guys to know that we are using a protocol where we perform some logic before making every request.


Here is the crash.

0
libsystem_platform.dylib 0x0000000199cd57d0 _OSSpinLockLockSlow$VARIANT$wfe + 160
1
CFNetwork 0x0000000183e034d4 CFURLProtocol_NS::forgetProtocolClient() + 32
2
OurApp 0x0000000101559c8c _GLOBAL__I_a + 2764
3
CFNetwork 0x0000000183f876a8 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke + 76
4
CFNetwork 0x0000000183f87638 -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 196
5
CFNetwork 0x0000000183f877ac -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 52
6
CFNetwork 0x0000000183df34fc ___ZN27URLConnectionClient_Classic26_delegate_didFinishLoadingEU13block_pointerFvvE_block_invoke + 96
7
CFNetwork 0x0000000183ee1b38 ___ZN27URLConnectionClient_Classic18_withDelegateAsyncEPKcU13block_pointerFvP16_CFURLConnectionPK33CFURLConnectionClientCurrent_VMaxE_block_invoke_2 + 104
8
libdispatch.dylib 0x0000000199ac56a8 _dispatch_client_callout + 12
9
libdispatch.dylib 0x0000000199ace9e4 _dispatch_block_invoke + 536
10
CFNetwork 0x0000000183ddfce4 RunloopBlockContext::_invoke_block() + 32
11
CoreFoundation 0x00000001845d86cc CFArrayApplyFunction + 64
12
CFNetwork 0x0000000183ddfbc8 RunloopBlockContext::perform() + 132
13
CFNetwork 0x0000000183ddfa88 MultiplexerSource::perform() + 308
14
CFNetwork 0x0000000183ddf8b4 MultiplexerSource::_perform() + 64
15
CoreFoundation 0x00000001846ac544 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 20
16
CoreFoundation 0x00000001846abfd8 __CFRunLoopDoSources0 + 536
17
CoreFoundation 0x00000001846a9cd8 __CFRunLoopRun + 720
18
CoreFoundation 0x00000001845d8ca0 CFRunLoopRunSpecific + 380
19
GraphicsServices 0x000000018f814088 GSEventRunModal + 176
20
UIKit 0x0000000189cf0ffc UIApplicationMain + 200
21
OurApp 0x00000001000372dc main + 120
22
libdyld.dylib 0x0000000199af68b8 start + 0



Any help would be greatly appreciated.


Thank you,


Marc.

Replies

I experience a very similar crash within my App. I'm implementing my own NSURLProtocol for HTTP which uses the NSURLSession API internally. These crashes have started with iOS 8 and continue with iOS 9. But these are rare, so it's almost impossible to debug. You can use the App for days or even weeks without encountering this crash, and sometimes you get it several times a day.


The Code that is running within my App is just the delegate which is called by the iOS when the connection has finished. After some postprocessing of the data my App is just notifying the NSURLProtocol client than the connection is finished: [self.client URLProtocolDidFinishLoading:self]; And this is where the crash occurs.


The connections are coming from UIWebView.


Did you solve this issue or do you have an idea how to prevent these crashes?



0   libsystem_platform.dylib    0x00000001812217d0 _os_lock_corruption_abort + 0
1   libsystem_platform.dylib    0x00000001812217d0 _os_lock_corruption_abort + 0
2   CFNetwork                   0x0000000181ba3308 CFURLProtocol_NS::forgetProtocolClient() + 36
3   MyApp                       0x0000000100324004 0x1000f4000 + 2293764
4   MyApp                       0x000000010024b0a0 0x1000f4000 + 1405088
5   CFNetwork                   0x0000000181cba1d8 __51-[NSURLSession delegate_task:didCompleteWithError:]_block_invoke170 + 72
6   Foundation                  0x0000000181f64334 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
7   Foundation                  0x0000000181eb7100 -[NSBlockOperation main] + 96
8   Foundation                  0x0000000181ea7348 -[__NSOperationInternal _start:] + 604
9   Foundation                  0x0000000181f66728 __NSOQSchedule_f + 224
10  libdispatch.dylib           0x00000001810115f0 _dispatch_client_callout + 16
11  libdispatch.dylib           0x000000018101d634 _dispatch_queue_drain + 864
12  libdispatch.dylib           0x00000001810150f4 _dispatch_queue_invoke + 464
13  libdispatch.dylib           0x000000018101f504 _dispatch_root_queue_drain + 728
14  libdispatch.dylib           0x000000018101f224 _dispatch_worker_thread3 + 112
15  libsystem_pthread.dylib     0x0000000181225470 _pthread_wqthread + 1092
16  libsystem_pthread.dylib     0x0000000181225020 start_wqthread + 4

I didn't fix it yet...


But yeah, I am implementing the custom NSURLProtocol like you do but using NSURLConnection instead of NSURLSession, and I am getting the crash in the same place you are getting it. It happens on the delegate method of connectionDidFinishLoading when I am trying to call [[self client] URLProtocolDidFinishLoading:self];

Seems to be a bug within NSURLConnection, probably some kind of race-condition, so it's hard to reproduce and provide a demo app. Nevertheless, if you haven't done so, please send a bug report to Apple.

How could it be an NSURLConnection bug if you are using NSURLSession? Then it should not happen to you, am I right?

Sorry, I meant that this is a bug within NSURLProtocol.

Hello guys,


Did apple or someone else provided with a fix for this ?


Thank you!

The case described in second post is exactly my case. 😐

I really hope there will be a solution to this error.

Have anyone tried wrapping offending method with try/catch? Does it help?


Thanks.

No, try/catch does not help here. I've tried this already, without success. But something other has helped...


I think the problem can be solved by following the threading rules that are descibed here:

https://developer.apple.com/library/ios/samplecode/CustomHTTPProtocol/Listings/Read_Me_About_CustomHTTPProtocol_txt.html


Unfortunately the public API documentation for NSURLProtocol is kind of "incomplete", because it is missing extremly important information about threading. You'll find this information only in the comments from the above sample code. Apple should really update their API documentation...


It looks like NSURLProtocol is not really "thread-safe" (at least not anymore, in older iOS releases this was never a problem). You have to make sure that all callbacks to the NSURLProtocolClient are made from within the same thread from which the "startLoading" method was called. You need to remember the current thread and runloop modes within the "startLoading" method, so you can later perform all calls to NSURLProtocolClient in the same thread and for the same runloop modes. Another thing you need to take care of is to detect recursive calls to your NSURLProtocol methods, so you do not release your own network or NSURLProtocol object while it is already released. If you do not synchronize your method calls correctly, a crash can happen, and the crash log would exactly look like the one from above.



Since I've changed my code to follow the threading rules from the sample code, I haven't seen this crash anymore. So I would say, this is not a bug within the IOS, it's just a "bug" in the documentation for NSURLProtocol, which just forgets to mention the most important facts..

do you know why `You have to make sure that all callbacks to the NSURLProtocolClient are made from within the same thread from which the "startLoading" method was called.` ?

do you know why “You have to make sure that all callbacks to the

NSURLProtocolClient
are made from within the same thread from which the "startLoading" method was called.” ?

Because that’s the way that the API was designed. The

NSURLProtocol
design dates back to the very early days of Safari, where Foundation URL loading wasn’t yet part of Foundation but shipped with Safari itself. We’ve revisited many of those design decisions since then, hence
NSURLSession
, but the
NSURLProtocol
design has not been updated.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"