v2: WebKit::XPCServiceEventHandler block should call exit() on the main thread

• Component: WebKit2
• Status: RESOLVED FIXED

[David Kilzer (:ddkilzer)]

WebKit::XPCServiceEventHandler block should call exit() on the main thread.

The fix in Bug 216594 / r267206 didn't work because apparently libdispatch thought the main thread was the current thread (maybe since this happened during exit():

Thread 0:: Dispatch queue: com.apple.main-thread
0   libSC.dylib                   	0x00007fff5df818f5 void std::__1::__tree_remove<std::__1::__tree_node_base<void*>*>(std::__1::__tree_node_base<void*>*, std::__1::__tree_node_base<void*>*) + 565
1   libSC.dylib                   	0x00007fff5df81296 boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister() + 598
2   libSC.dylib                   	0x00007fff5e116a1f boost::serialization::detail::singleton_wrapper<boost::serialization::extended_type_info_typeid<_SC_CI_TRANSFORM_SHADER_DESC> >::~singleton_wrapper() + 47
3   libsystem_c.dylib             	0x00007fff20324ca7 __cxa_finalize_ranges + 316
4   libsystem_c.dylib             	0x00007fff20324f92 exit + 53
5   com.apple.WebKit              	0x00007fff3c627bcc invocation function for block in WebKit::AuxiliaryProcess::stopNSRunLoop() + 11
6   com.apple.CoreFoundation      	0x00007fff204f05a2 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
7   com.apple.CoreFoundation      	0x00007fff204f044c __CFRunLoopDoBlocks + 437
8   com.apple.CoreFoundation      	0x00007fff204ef132 __CFRunLoopRun + 907
9   com.apple.CoreFoundation      	0x00007fff204ee6ce CFRunLoopRunSpecific + 563
10  com.apple.Foundation          	0x00007fff212786d1 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
11  com.apple.Foundation          	0x00007fff21306ab4 -[NSRunLoop(NSRunLoop) run] + 76
12  libxpc.dylib                  	0x00007fff201473dd _xpc_objc_main + 825
13  libxpc.dylib                  	0x00007fff20146e65 xpc_main + 437
14  com.apple.WebKit              	0x00007fff3c5dc3d2 WebKit::XPCServiceMain(int, char const**) + 629
15  libdyld.dylib                 	0x00007fff20413591 start + 1

[...]

Thread 3 Crashed:: Dispatch queue: com.apple.root.default-qos
0   libSC.dylib                   	0x00007fff5df80e65 boost::serialization::typeid_system::extended_type_info_typeid_0::is_less_than(boost::serialization::extended_type_info const&) const + 21
1   libSC.dylib                   	0x00007fff5df810dc boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister() + 156
2   libSC.dylib                   	0x00007fff5e1165bf boost::serialization::detail::singleton_wrapper<boost::serialization::extended_type_info_typeid<_SC_PRIMSHADER_VPORT_CONTROLS_LUT> >::~singleton_wrapper() + 47
3   libsystem_c.dylib             	0x00007fff20324ca7 __cxa_finalize_ranges + 316
4   libsystem_c.dylib             	0x00007fff20324f92 exit + 53
5   com.apple.WebKit              	0x00007fff3c5dd755 invocation function for block in WebKit::XPCServiceEventHandler(NSObject<OS_xpc_object>*) + 616
6   libxpc.dylib                  	0x00007fff2013ec28 _xpc_connection_call_event_handler + 56
7   libxpc.dylib                  	0x00007fff2013d90c _xpc_connection_mach_event + 535
8   libdispatch.dylib             	0x00007fff2024c867 _dispatch_client_callout4 + 9
9   libdispatch.dylib             	0x00007fff20266ec0 _dispatch_mach_cancel_invoke + 65
10  libdispatch.dylib             	0x00007fff202647f4 _dispatch_mach_invoke + 1070
11  libdispatch.dylib             	0x00007fff2025cc5d _dispatch_workloop_worker_thread + 819
12  libsystem_pthread.dylib       	0x00007fff203f4499 _pthread_wqthread + 314
13  libsystem_pthread.dylib       	0x00007fff203f3467 start_wqthread + 15

[David Kilzer (:ddkilzer)]

<rdar://problem/70275659>

[David Kilzer (:ddkilzer)]

Created attachment 411471 [details]
Patch v1

[Geoffrey Garen]

Yes, during exit libdispatch somewhat randomly picks a new thread to be the "main queue" thread. I have seen many cases where this behavior confused someone and no cases where it helped someone. Oh well.

To clarify, it's not that the *current* thread became the main queue thread; that would have caused a deadlock. Instead, some *other* thread became the main queue thread, and we called exit() on that thread.

[Geoffrey Garen]

Comment on attachment 411471 [details]
Patch v1

r=me

[David Kilzer (:ddkilzer)]

Committed r268570: <https://trac.webkit.org/changeset/268570>

[David Kilzer (:ddkilzer)]

(In reply to David Kilzer (:ddkilzer) from comment #5)
> Committed r268570: <https://trac.webkit.org/changeset/268570>

Just modified the commit log message to reflect Geoff's comments in Comment #3.