After re-reading some of the forum threads and TN, am I understanding correctly that content filters are only available on iOS 15 and above for apps that use Family Controls to request authorization for .child, not .indvidual? Trying to save a content filter configuration after requesting individual authorization throws a permission denied error in a TestFlight build.
https://developer.apple.com/documentation/technotes/tn3134-network-extension-provider-deployment also mentions that it is available on "per-app on managed devices". Is this completed unrelated to Family Controls?
bpsym
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Putting the message that we only see in Crashlytics aside, the Xcode Organizer crash reports (attached in a previous message and in the FB) closely matches what we see in Crashlytics. Is there anything we could infer from them?
Hi Eskimo, any luck or updates regarding this issue? I've also filed FB8970895 to track this.
Thanks, Eskimo. From my side, I no longer see these crashes in 14.3, only 14.2 and below.
We're still running into issue unfortunately. Any ideas on what's causing this issue would be greatly appreciated. We've heard of one report mentioning this crash when launching the app.
Here's a full crash report for the issue: _xpc_connection_release_message.cold.2 - https://developer.apple.com/forums/content/attachment/478090ca-36b3-44cf-acbe-4835284d3e7d
Any updates or ideas on what's happening in the stack by any chance?
Here's the symbolicated version:
Symbolicated 0xdead10cc crash log - https://developer.apple.com/forums/content/attachment/54bacde9-5f67-4e76-b126-41270e76c059
Can you post an example crash record for this 0xdead10cc crash? Not
just a snippet, but the whole report. Use the text attachment feature
to avoid clogging up the timeline. Please see:
0xdead10cc Crash Log - https://developer.apple.com/forums/content/attachment/13e7a152-33e1-43b1-a563-bc98fc81d874
SIGTRAP usually means you’ve hit a Swift runtime trap, like force unwrapping a nil value or accessing an array out of bounds. That’s clearly a worry. Thanks!
One additional question that came to mind was what the crash logs would look like if there were no open locks but the extension blocked stopWithReason long enough.
I do see other crash logs with a similar stopWithReason stack trace that I've previous posted but with a different exception type/code. Does this indicate the blocking issue?
Exception Type:	EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001047dfdc4
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [14635]
Triggered by Thread:	1
Is there any chance that frame 0 (PacketTunnelProvider.swift:475) is blocked for extended periods of time? Ah... it might. How much time does an extension have to call the completionHandler? Not seeing any times in https://developer.apple.com/documentation/networkextension/nepackettunnelprovider/1406192-stoptunnel
What do frames 4 through 0 in that backtrace look like? The frames are handling the stopTunnel call before the completionHandler should be called.
From a similar crash log's stack trace:
Thread 1 name:
Thread 1:
0	 <Framework>													 0x0000000104e0bdc4 <Framework>PacketTunnelProvider.handleExiting(displayNotification:) + 1772 (<Framework>PacketTunnelProvider.swift:475)
1	 <Framework>													 0x0000000104e0b9c8 <Framework>ConfigKey.ENABLED.unsafeMutableAddressor + 36 (<Framework>ConfigKey.swift:36)
2	 <Framework>													 0x0000000104e0b9c8 <Framework>PacketTunnelProvider.handleExiting(displayNotification:) + 752 (<Framework>PacketTunnelProvider.swift:438)
3	 <Framework>													 0x0000000104e0b460 <Framework>PacketTunnelProvider.stopTunnel(with:completionHandler:) + 532 (<Framework>PacketTunnelProvider.swift:422)
4	 <Framework>													 0x0000000104e0b6bc @objc <Framework>PacketTunnelProvider.stopTunnel(with:completionHandler:) + 96 (<compiler-generated>:0)
5	 NetworkExtension							 0x0000000195258f9c -[NEExtensionPacketTunnelProviderContext stopWithReason:] + 272 (NEExtensionPacketTunnelProviderContext.m:63)
6	 CoreFoundation								 0x00000001849b8870 invoking_ + 144
7	 CoreFoundation								 0x000000018489bfd0 -[NSInvocation invoke] + 300 (NSForwarding.m:3389)
8	 Foundation										 0x0000000185d3cd24 NSXPCCONNECTION_IS_CALLING_OUT_TO_EXPORTED_OBJECT + 20 (NSXPCConnection.m:252)
9	 Foundation										 0x0000000185b7a87c -[NSXPCConnection _decodeAndInvokeMessageWithEvent:flags:] + 1308 (NSXPCConnection.m:776)
10	Foundation										 0x0000000185d3ce78 message_handler + 224 (NSXPCConnection.m:866)
11	libxpc.dylib									 0x00000001ca27c454 _xpc_connection_call_event_handler + 68 (connection.c:0)
12	libxpc.dylib									 0x00000001ca27c7d0 _xpc_connection_mach_event + 880 (connection.c:1218)
13	libdispatch.dylib						 0x00000001845ed340 _dispatch_client_callout4 + 16 (object.m:599)
14	libdispatch.dylib						 0x00000001845a6e10 _dispatch_mach_msg_invoke$VARIANT$mp + 384 (mach.c:2429)
15	libdispatch.dylib						 0x0000000184595e70 _dispatch_lane_serial_drain$VARIANT$mp + 300 (inline_internal.h:2589)
16	libdispatch.dylib						 0x00000001845a7a18 _dispatch_mach_invoke$VARIANT$mp + 472 (mach.c:2751)
17	libdispatch.dylib						 0x0000000184595e70 _dispatch_lane_serial_drain$VARIANT$mp + 300 (inline_internal.h:2589)
18	libdispatch.dylib						 0x0000000184596ab4 _dispatch_lane_invoke$VARIANT$mp + 472 (queue.c:3862)
19	libdispatch.dylib						 0x00000001845a0518 _dispatch_workloop_worker_thread + 712 (queue.c:6590)
20	libsystem_pthread.dylib			 0x00000001ca25c5a4 _pthread_wqthread + 272 (pthread.c:2193)
21	libsystem_pthread.dylib			 0x00000001ca25f874 start_wqthread + 8
Thanks for the clarifications as always!
> Does this mean that the extension should release all locks before
calling stopWithReason's completion handler? Yes. I'm still a bit confused by the timing since I see a few (not all) crashes with some background threads still handling stopWithReason and hasn't called the completionHandler yet. Any thoughts on what is happening there?
Thread 8 name:
Thread 8:
...
5	 NetworkExtension							 0x00000001a8115f9c -[NEExtensionPacketTunnelProviderContext stopWithReason:] + 272 (NEExtensionPacketTunnelProviderContext.m:63)
6	 CoreFoundation								 0x0000000197875870 invoking_ + 144
7	 CoreFoundation								 0x0000000197758fd0 -[NSInvocation invoke] + 300 (NSForwarding.m:3389)
8	 Foundation										 0x0000000198bf9d24 NSXPCCONNECTION_IS_CALLING_OUT_TO_EXPORTED_OBJECT + 20 (NSXPCConnection.m:252)
9	 Foundation										 0x0000000198a3787c -[NSXPCConnection _decodeAndInvokeMessageWithEvent:flags:] + 1308 (NSXPCConnection.m:776)
10	Foundation										 0x0000000198bf9e78 message_handler + 224 (NSXPCConnection.m:866)
11	libxpc.dylib									 0x00000001dd174454 _xpc_connection_call_event_handler + 68 (connection.c:0)
12	libxpc.dylib									 0x00000001dd1747d0 _xpc_connection_mach_event + 880 (connection.c:1218)
13	libdispatch.dylib						 0x00000001974aa340 _dispatch_client_callout4 + 16 (object.m:599)
14	libdispatch.dylib						 0x0000000197463e10 _dispatch_mach_msg_invoke$VARIANT$mp + 384 (mach.c:2429)
15	libdispatch.dylib						 0x0000000197452e70 _dispatch_lane_serial_drain$VARIANT$mp + 300 (inline_internal.h:2589)
16	libdispatch.dylib						 0x0000000197464a18 _dispatch_mach_invoke$VARIANT$mp + 472 (mach.c:2751)
17	libdispatch.dylib						 0x0000000197452e70 _dispatch_lane_serial_drain$VARIANT$mp + 300 (inline_internal.h:2589)
18	libdispatch.dylib						 0x0000000197453ab4 _dispatch_lane_invoke$VARIANT$mp + 472 (queue.c:3862)
19	libdispatch.dylib						 0x000000019745d518 _dispatch_workloop_worker_thread + 712 (queue.c:6590)
20	libsystem_pthread.dylib			 0x00000001dd1545a4 _pthread_wqthread + 272 (pthread.c:2193)
21	libsystem_pthread.dylib			 0x00000001dd157874 start_wqthread + 8
Thanks! Filed FB8779823 and attached some full crash logs to it.