Memory leak in NSURLSession uploading task?

Hi,


I am uploading a large file, and have checked this scenario for memory leaks with Instruments.

It reports 5 leaked objects (about 250 bytes).

I have tested on Simulator for iPhone 6. I am linking with iOS / SDK 10.3.


Actually, I am using only the NSURLSession method

- uploadTaskWithRequest:fromFile:completionHandler:

and the NSURLSessionTaskDelegate method for the authentication

- URLSession:task:didReceiveChallenge:completionHandler:


As far as I understand, the root cause is some kind of intermediate error which happens during the transmission, and the error object (NSCFError) leaks.

Instruments shows me the calling tree of the leak very deep in the system.

In the console I see error messages like


[] nw_endpoint_handler_add_write_request [21.1 ::1.7779 failed socket-flow (satisfied)] cannot accept write requests

[] tcp_connection_write_eof_block_invoke Write close callback received error: [22] Invalid argument

or:

[] nw_socket_write_close shutdown(9, SHUT_WR): [57] Socket is not connected

[] nw_endpoint_flow_service_writes [9.1 ::1.7779 ready socket-flow (satisfied)] Write request has 0 frame count, 0 byte count

[] tcp_connection_write_eof_block_invoke Write close callback received error: [89] Operation canceled


I am out of ideas how to continue with my analysis.

Should I worry about this? (after all, it is „only“ 250 bytes, and it does not happen every time).

Is there any known issue with NSURLSession related to this?

Up vote post of ndegendogo Down vote post of ndegendogo
1.6k views
Posted by
ndegendogo
Reply
Add a Comment

Accepted Reply

The question here is whether this might be a false positive. It's not impossible that the errors are being created as a result of network failure and intentionally not being released. (It may be cheaper to keep a finite number of small objects around, than to re-create them multiple times for multiple error events.) It's also possible that they're not unreferenced, but tracked in a way that Instruments does not recognize.


Can you cause additional errors to be "leaked"? For example, if you start a new session that leads to the same log messages, are there 5 more leaked objects?


If not, then perhaps it's not worth worrying about. If you can, then a bug report seems appropriate — errors created deep within the bowels of the system, especially if not reported to your code directly, seem like they're not your problem.

Posted by
QuinceyMorris
Up vote reply of QuinceyMorris Down vote reply of QuinceyMorris
Post marked as solved
Add a Comment

Replies

I forgot to mention that I am implementing in Objective C with ARC

Posted by
ndegendogo
Up vote reply of ndegendogo Down vote reply of ndegendogo
Add a Comment

The question here is whether this might be a false positive. It's not impossible that the errors are being created as a result of network failure and intentionally not being released. (It may be cheaper to keep a finite number of small objects around, than to re-create them multiple times for multiple error events.) It's also possible that they're not unreferenced, but tracked in a way that Instruments does not recognize.


Can you cause additional errors to be "leaked"? For example, if you start a new session that leads to the same log messages, are there 5 more leaked objects?


If not, then perhaps it's not worth worrying about. If you can, then a bug report seems appropriate — errors created deep within the bowels of the system, especially if not reported to your code directly, seem like they're not your problem.

Posted by
QuinceyMorris
Up vote reply of QuinceyMorris Down vote reply of QuinceyMorris
Post marked as solved
Add a Comment

Yes, may well be a false positive.

After all:

- I was testing with simulator only instead of true device

- I opened the session to localhost instead of a true WLAN connection to a separate host

It may well be that the leak is happening so deep in the system layers of the simulator / other network stack.


Next step will be to watch the same scenario with the true code (true device, WLAN session).

As you recommend, I don't worry too much, but I want to get more practice with Instruments.


And, yes, you are right. It may be the system strategy to create this error object lazily; and the object may be addressed with pointers from a C union (or even from Assembler code) which will be hard to detect for a tool like Instruments.

Posted by
ndegendogo
Up vote reply of ndegendogo Down vote reply of ndegendogo
Add a Comment