Switching to async is not ideal for me, unless you can suggest
another way to simulate blocking I/O. I'm running each connection on
a distinct thread.
As such, I changed my setup code to ignore the cache:
NSMutableURLRequest *urlRequest = [NSMutableURLRequest
requestWithURL:url
cachePolicy:NSURLRequestReloadIgnoringLocalCacheData timeoutInterval:
60.0];
This seems to have suppressed the leak, although I'm now seeing
another 3.5KB leak stemming from an NSOperation:
12 3.50 Kb 0x0
11 libSystem.B.dylib 3.50 Kb _pthread_body
10 Foundation 3.50 Kb __NSThread__main__
9 Foundation 3.50 Kb -[NSThread main]
8 Foundation 3.50 Kb -[NSOperation start]
7 Foundation 3.50 Kb -
[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:]
6 Foundation 3.50 Kb NSKVONotify
5 Foundation 3.50 Kb +[NSOperation
observeValueForKeyPath:ofObject:change:context:]
4 Foundation 3.50 Kb __finishedOp
3 Foundation 3.50 Kb __scheduleAll
2 Foundation 3.50 Kb -[NSThread start]
1 libSystem.B.dylib 3.50 Kb pthread_create
0 libSystem.B.dylib 3.50 Kb malloc
I don't think this is networking related, but is still somewhat
mysterious.
- Ladd
On Nov 12, 2008, at 1:10 PM, Mark Pauley wrote:
So it turns out we were aware of this issue, and we know what's
wrong. We should address this at some point in the future, but for
now please stick with the asynchronous version of the API to avoid
the leak. Alternatively, I believe that turning off the NSURLCache
on a per request basis may work around this.
Please let me know if either of those two don't work for you.
