Bug 217773 - v2: WebKit::XPCServiceEventHandler block should call exit() on the main thread
Summary: v2: WebKit::XPCServiceEventHandler block should call exit() on the main thread
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: David Kilzer (:ddkilzer)
URL:
Keywords: InRadar
Depends on: 216594
Blocks:
  Show dependency treegraph
 
Reported: 2020-10-15 11:42 PDT by David Kilzer (:ddkilzer)
Modified: 2020-10-15 18:54 PDT (History)
3 users (show)

See Also:


Attachments
Patch v1 (2.80 KB, patch)
2020-10-15 12:00 PDT, David Kilzer (:ddkilzer)
ggaren: review+
ddkilzer: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Kilzer (:ddkilzer) 2020-10-15 11:42:30 PDT
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
Comment 1 David Kilzer (:ddkilzer) 2020-10-15 11:46:08 PDT
<rdar://problem/70275659>
Comment 2 David Kilzer (:ddkilzer) 2020-10-15 12:00:55 PDT
Created attachment 411471 [details]
Patch v1
Comment 3 Geoffrey Garen 2020-10-15 16:27:38 PDT
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.
Comment 4 Geoffrey Garen 2020-10-15 16:31:38 PDT
Comment on attachment 411471 [details]
Patch v1

r=me
Comment 5 David Kilzer (:ddkilzer) 2020-10-15 18:45:34 PDT
Committed r268570: <https://trac.webkit.org/changeset/268570>
Comment 6 David Kilzer (:ddkilzer) 2020-10-15 18:54:46 PDT
(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.