I frequently hit the following assertion when closing tabs: ASSERTION FAILED: sendRightCount == 1 /Volumes/Data/cdumez/WebKit/OpenSource/Source/WebKit/UIProcess/Launcher/mac/ProcessLauncherMac.mm(218) : auto WebKit::ProcessLauncher::launchProcess()::(anonymous class)::operator()(xpc_object_t) const 1 0x10f218e49 WTFCrash 2 0x114d327ab WebKit::ProcessLauncher::launchProcess()::$_0::operator()(NSObject<OS_xpc_object>*) const 3 0x114d326b1 invocation function for block in WebKit::ProcessLauncher::launchProcess()::$_0::operator void (NSObject<OS_xpc_object>*) block_pointer() const 4 0x7fff6241ae60 _xpc_connection_call_event_handler 5 0x7fff6241940b _xpc_connection_mach_event 6 0x7fff6219b1ff _dispatch_client_callout4 7 0x7fff6219d790 _dispatch_mach_cancel_invoke 8 0x7fff6219a12d _dispatch_mach_invoke 9 0x7fff621a0e21 _dispatch_main_queue_callback_4CF 10 0x7fff350aa395 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ 11 0x7fff35074f3c __CFRunLoopRun 12 0x7fff350743f5 CFRunLoopRunSpecific 13 0x7fff3431b79b RunCurrentEventLoopInMode 14 0x7fff3431b4d5 ReceiveNextEventCommon 15 0x7fff3431b252 _BlockUntilNextEventMatchingListInModeWithFilter 16 0x7fff32603a9e _DPSNextEvent 17 0x7fff32d49b76 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 18 0x10cb99590 -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 19 0x7fff325f91a5 -[NSApplication run] 20 0x7fff325c8c70 NSApplicationMain 21 0x10d4955aa SafariMain 22 0x10c9ddf82 main 23 0x7fff621d18d1 start 24 0x1 This assertion was added recently by Brent.
This assertion was meant to help identify cases where we had poor bookkeeping and attempted to remove send rights that we did not have. Limiting the assertion to a single send-right is probably too conservative, since the port could have been granted other send-rights during other operations. I do think it would be worrisome to attempt to remove a send right when we don't have one (that would indicate an out-of-balance condition, and possible corruption of the port space). Let's change the assertion to check that we have AT LEAST ONE send right before we remove it.
<rdar://problem/39386361>
Created attachment 341209 [details] Patch
Comment on attachment 341209 [details] Patch Clearing flags on attachment: 341209 Committed r232160: <https://trac.webkit.org/changeset/232160>
All reviewed patches have been landed. Closing bug.
Comment on attachment 341209 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=341209&action=review > Source/WebKit/UIProcess/Launcher/mac/ProcessLauncherMac.mm:218 > - ASSERT(sendRightCount == 1); > + ASSERT(sendRightCount >= 1); This essentially checks that sendRightsCount is not 0. Is it possible to have a port with zero send rights?
(In reply to Anders Carlsson from comment #6) > Comment on attachment 341209 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=341209&action=review > > > Source/WebKit/UIProcess/Launcher/mac/ProcessLauncherMac.mm:218 > > - ASSERT(sendRightCount == 1); > > + ASSERT(sendRightCount >= 1); > > This essentially checks that sendRightsCount is not 0. Is it possible to > have a port with zero send rights? Yes - though I'm not sure under what circumstances that happens. Apparently you can pass send rights around, but I don't believe WebKit attempts to do that.