NEPacketTunnelProvider runs fine when compiled against iOS 13.1, but crashes against 13.2 & 13.3

During tests with Xcode 11.2.x and vpn apps I am maintaining, I noticed that extensions using NEPacketTunnelProvider are crashing directly before any custom code is run.


After adding an UncaughtExeptionHandler it became clear that the crash happens within NEPacketTunnelProvider's own init().


The crash happens on iPhones and iPads rangeing from iOS 10.3 to 13.2.

The crash happens wen compiling against iOS 13.2 or later. (Xcode 11.2, 11.2.1 or 11.3 beta (11C24b).)

It doesnt happen when compiling against iOS 13.1 and earlyer. (Xcode 11.1.)

(Seems we still deliver the Swift libraries with our Apps, don't we.)


This is a big issue as we cant use Xcode 11.2 or later for production until this is fixed.


Please see the provoded example project for your reference. It consists of a network extension and a button that triggers the tunnel creation.

The example project can be found here.

https://files.fm/u/9mnkks48


Stacktraces:

All stacktraces are identical. Noteable is line 10 where a NSMutableDictionary is trying to set an object for a key.

libsystem_kernel.dylib 0x1af45acc __pthread_kill + 8
libsystem_pthread.dylib 0x1affe086 pthread_kill + 62
libsystem_c.dylib 0x1aeda95a abort + 108
libc++abi.dylib 0x1a9df708 __cxa_bad_cast + 0
libc++abi.dylib 0x1a9f6552 default_unexpected_handler+ 99666 () + 0
libobjc.A.dylib 0x1a9ff31e _objc_terminate+ 29470 () + 234
libc++abi.dylib 0x1a9f398e std::__terminate(void (*)+ 88462 ()) + 78
libc++abi.dylib 0x1a9f31a2 __cxxabiv1::exception_cleanup_func+ 86434 (_Unwind_Reason_Code, _Unwind_Exception*) + 0
libobjc.A.dylib 0x1a9ff138 _objc_exception_destructor+ 28984 (void*) + 0
CoreFoundation 0x1b68c88c -[__NSDictionaryM setObject:forKey:] + 838
Foundation 0x1c05da32 -[_NSExtensionContextVendor _setPrincipalObject:forUUID:] + 96
Foundation 0x1c05d20a __105-[_NSExtensionContextVendor _beginRequestWithExtensionItems:listenerEndpoint:withContextUUID:completion:]_block_invoke + 890
libdispatch.dylib 0x1ae45796 _dispatch_call_block_and_release + 10
libdispatch.dylib 0x1ae5259c _dispatch_queue_serial_drain + 854
libdispatch.dylib 0x1ae48b70 _dispatch_queue_invoke + 886
libdispatch.dylib 0x1ae52a1e _dispatch_queue_override_invoke + 282
libdispatch.dylib 0x1ae541b4 _dispatch_root_queue_drain + 326
libdispatch.dylib 0x1ae5400e _dispatch_worker_thread3 + 106
libsystem_pthread.dylib 0x1affa87c _pthread_wqthread + 1040
libsystem_pthread.dylib 0x1affa45c start_wqthread + 8

Accepted Reply

Check out frame 11 of your backtrace,

-[_NSExtensionContextVendor _setPrincipalObject:forUUID:]
. It’s unlikely that the UUID is
nil
, but rather than the principal object is
nil
. I’ve seen this sort of thing before, where the system is unable to construct the extension’s principal object. These sorts of problem usually leave some sort of hint in the system log. Alas, I can’t tell you what to look for because there are so many potential causes.

Please see the provoded example project for your reference. It consists of a network extension and a button that triggers the tunnel creation. The example project can be found here.

I’m not sure if this is what’s causing the problem in your product, but that project has an entitlement issue. Specifically, the NetworkExtension entitlement is missing from the Packettunnel target. I fixed that by adding a Network Extensions capability in that target’s Signing & Capabilities editor, and then checking Packet Tunnel. After that I ran your app, tapped the button, and the provider loaded just fine (I was able to attach to it Debug > Attach to Process).

This was Xcode 11.2 targeting iOS 13.2.

Share and Enjoy

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

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

Replies

Check out frame 11 of your backtrace,

-[_NSExtensionContextVendor _setPrincipalObject:forUUID:]
. It’s unlikely that the UUID is
nil
, but rather than the principal object is
nil
. I’ve seen this sort of thing before, where the system is unable to construct the extension’s principal object. These sorts of problem usually leave some sort of hint in the system log. Alas, I can’t tell you what to look for because there are so many potential causes.

Please see the provoded example project for your reference. It consists of a network extension and a button that triggers the tunnel creation. The example project can be found here.

I’m not sure if this is what’s causing the problem in your product, but that project has an entitlement issue. Specifically, the NetworkExtension entitlement is missing from the Packettunnel target. I fixed that by adding a Network Extensions capability in that target’s Signing & Capabilities editor, and then checking Packet Tunnel. After that I ran your app, tapped the button, and the provider loaded just fine (I was able to attach to it Debug > Attach to Process).

This was Xcode 11.2 targeting iOS 13.2.

Share and Enjoy

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

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

Thank you. 🙂 That was it indeed. 😊