Open Radar

 
Summary:
Many of the users of my application are experiencing a read access violation in iOS 8 that they did not experience in iOS 7 when the app is performing many http downloads using NSURLConnection.
 
I have been able to reproduce the issue in the debugger. When running with "guard edges" on, I see many, many errors reported from libsystem_malloc.dylib`protect such as:
 
malloc: *** can't protect(0x3) region for postlude guard page at 0x808c000
 
Although the logging is not the crash, it is clear that CFCachedURLResponse is attempting to free a bogus memory address.
 
Occasionally, when there is a high volume of this logging, other code will induce a read access violation with an address very close to the memory address that induced the error message above.
 
I'm inferring that the CFCachedURLResponse code has a bug that causes it to be confused about the memory addresses it is responsible for freeing - sometimes freeing memory allocated by other parts of the system.

Steps to Reproduce:
Note that this does NOT happen in iOS 7. Nor does it happen in the iOS 8 simulator.
 
- Load this app into xcode - https://github.com/epatey/URLCrash
- Turn on "Enable Guard Edges"
- Run in the debugger
- Set a breakpoint in malloc_printf


Expected Results:
No error messages or crashes

Actual Results:
- malloc_printf will be called by protect very often
- note the call stack will be on the com.apple.CFNetwork.addPersistCacheToStorageDaemon queue while freeing a CFCachedURLResponse
- occasionally, the app will crash when freeing an NSData int the following code.
            @autoreleasepool {
                @synchronized(datas) {
                    if (datas.count > maxDatas) {
                        [datas removeObjectAtIndex:0];
                    }
                }
            }