Crashed: ne.filter [iOS12]

Dear eskimo and community,


After upgrading to iOS12 we are receiving a lot of crashreports connected to EXC_BAD_ACCESS KERN_INVALID_ADDRESS on ne.filter thread.

I can assume that smth is wrong with libnetwork.dylib. The same app version works fine on all previous iOS versions.

The issue occurs sporadically so we are not able to reproduce it with a connected debugger.


About 3% of users are impacted

Would you be so kind to give some recommendations on how to fix this if that is possible from our side?


Below you can find different stacktraces of crashed thread:


Crashed: ne.filter
0  libobjc.A.dylib                0x20be90430 objc_retain + 16
1  libnetwork.dylib               0x20def9124 nw_queue_context_async + 24
2  libnetworkextension.dylib      0x21882bf48 __ne_filter_data_protocol_send_new_flow_block_invoke + 428
3  libxpc.dylib                   0x20c909514 _xpc_connection_reply_callout + 60
4  libxpc.dylib                   0x20c8fcb3c _xpc_connection_call_reply_async + 88
5  libdispatch.dylib              0x20c6e3504 _dispatch_client_callout3 + 16
6  libdispatch.dylib              0x20c69b8c4 _dispatch_mach_msg_async_reply_invoke$VARIANT$mp + 320
7  libdispatch.dylib              0x20c68aae4 _dispatch_lane_serial_drain$VARIANT$mp + 284
8  libdispatch.dylib              0x20c68b760 _dispatch_lane_invoke$VARIANT$mp + 432
9  libdispatch.dylib              0x20c693f00 _dispatch_workloop_worker_thread + 600
10 libsystem_pthread.dylib        0x20c8c50f0 _pthread_wqthread + 312
11 libsystem_pthread.dylib        0x20c8c7d00 start_wqthread + 4


Crashed: ne.filter
0  libdispatch.dylib              0x23aab7e50 dispatch_async$VARIANT$mp + 160
1  libnetwork.dylib               0x23c329164 nw_queue_context_async + 88
2  libnetworkextension.dylib      0x246c5bf48 __ne_filter_data_protocol_send_new_flow_block_invoke + 428
3  libxpc.dylib                   0x23ad39514 _xpc_connection_reply_callout + 60
4  libxpc.dylib                   0x23ad2cb3c _xpc_connection_call_reply_async + 88
5  libdispatch.dylib              0x23ab13504 _dispatch_client_callout3 + 16
6  libdispatch.dylib              0x23aacb8c4 _dispatch_mach_msg_async_reply_invoke$VARIANT$mp + 320
7  libdispatch.dylib              0x23aabaae4 _dispatch_lane_serial_drain$VARIANT$mp + 284
8  libdispatch.dylib              0x23aabb760 _dispatch_lane_invoke$VARIANT$mp + 432
9  libdispatch.dylib              0x23aac3f00 _dispatch_workloop_worker_thread + 600
10 libsystem_pthread.dylib        0x23acf50f0 _pthread_wqthread + 312
11 libsystem_pthread.dylib        0x23acf7d00 start_wqthread + 4

Replies

Would you be so kind to give some recommendations on how to fix this if that is possible from our side?

Please post a full crash report.

Share and Enjoy

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

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

Below you can find 4 versions of crashreports. All of them are similar.

Uploaded 4 crashreports to dropbox https://www.dropbox.com/sh/jryfxfk1jdmwffl/AAANko1hkBV3qpmZ_z_F7JWda?dl=0

Thanks. Alas, these are not Apple crash reports and I need an Apple crash report to make progress with this.

Share and Enjoy

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

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

@eskimo
Unfortunatelly those crashes are not recorded with Xcode. I can see those issues with Fabric crashlytics only. Also we were not able to reproduce it. However qty of affected users is rising and I would be happy if you can help me somehow based on provided reports.

Unfortunately third-party crash reports don’t contain the details necessary to debug hard problems. There’s actually two problems with the crash reports you posted:

  • There’s no assembly-level information at all (no Binary Images section, no Thread State section), which makes any sort of low-level debugging impossible.

  • Apple has internal tools for analysing crash reports, but they assume the Apple crash report format.

If you’re not getting Apple crash reports for this crash it’s possible that your third-party crash reporter is doing something to block that workflow. I recommend that you check that first.

Share and Enjoy

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

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

Issue was fixed by adding delegateQueue during initialisation of NSURLSession

NSURLSession *session = [NSURLSession sessionWithConfiguration:config
                                                          delegate:self
                                                     delegateQueue:self.operationQueue]

operation queue has maxConcurrentOperationCount = 5.
I hope that can save time for someone.


I was too optimistic regarding proposed solution. Still crashing with same stacktrace...