21484589: Race Condition in CustomHTTPProtocol between -stopLoading and URLSessionDataDelegate callbacks

[openradar-mirror]

Description

Summary: The CustomHTTPProtocol example code contains a race condition between the CustomHTTPProtocol.clientThread and QNSURLSessionDemux.sessionDelegateQueue. The following sequence of method calls is possible:

1. URLSession:dataTask:didReceiveData: on QNSURLSessionDemux.sessionDelegateQueue
2. stopLoading on CustomHTTPProtocol.clientThread
3. URLSession:dataTask:didReceiveData: on CustomHTTPProtocol.clientThread

This causes an assertion failure because stopLoading nils CustomHTTPProtocol.task, and all of the URLSessionDataDelegate callback methods assert(self.task == dataTask).

Steps to Reproduce: I was able to reproduce this by loading a page in UIWebView while CustomHTTPProtocol was active. Unfortunately, the page is internal, and I can't expose it to you. However, if should be easy to see in code that the above race condition is at least theoretically possible.

Expected Results: CustomHTTPProtocol should expect this race condition and handle it.

Actual Results: CustomHTTPProtocol traps when assert(self.task == dataTask) fails.

Product Version: Created: 2015-06-22T15:37:52.350340 Originated: 2015-06-22T10:35:00 Open Radar Link: http://www.openradar.me/21484589

[inantop]

I don't know what lionheart is, but https://developer.apple.com/library/content/samplecode/CustomHTTPProtocol/Introduction/Intro.html is apple sample code and I'm running into this problem as well when using a web view.

I find it's easily reproducible on the google home page due to what I'm assuming is the live search, steps to repro are to simply open http://google.com in a UIWebView with CustomHTTPProtocol active and then spam the input keys on the soft keyboard.

Was there any resolution to this?