Bug 185687 – REGRESSION(r230269): ASSERTION FAILED: sendRightCount == 1 at ProcessLauncherMac.mm(218)

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Chris Dumez]

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.

[Brent Fulgham]

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.

[Brent Fulgham]

<rdar://problem/39386361>

[Brent Fulgham]

Created attachment 341209 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 341209 [details]
Patch

Clearing flags on attachment: 341209

Committed r232160: <https://trac.webkit.org/changeset/232160>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Anders Carlsson]

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?

[Brent Fulgham]

(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.