Bug 147122 – ASSERT(m_suspendMessageCount >= 0) fails in ProcessThrottler::didCancelProcessSuspension() when WebContent process crashes; Network process may never voluntarily suspend

• Component: WebKit2
• Status: RESOLVED FIXED

[Daniel Bates]

Using a debug device build of WebKit for iOS r186893, the assertion ASSERT(m_suspendMessageCount >= 0) fails ProcessThrottler::didCancelProcessSuspension() when switching tabs with the following backtrace:

Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: ASSERTION FAILED: m_suspendMessageCount >= 0
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: /Volumes/Data/WebKitDevGit/OpenSource/Source/WebKit2/UIProcess/ProcessThrottler.cpp(114) : void WebKit::ProcessThrottler::didCancelProcessSuspension()
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 1   0x100c25c20 WTFCrash
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 2   0x109e4d928 WebKit::ProcessThrottler::didCancelProcessSuspension()
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 3   0x109dd501c WebKit::NetworkProcessProxy::didCancelProcessSuspension()
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 4   0x109ddb440 void IPC::callMemberFunctionImpl<WebKit::NetworkProcessProxy, void (WebKit::NetworkProcessProxy::*)(), std::__1::tuple<> >(WebKit::NetworkProcessProxy*, void (WebKit::NetworkProcessProxy::*)(), std::__1::tuple<>&&, std::index_sequence<>)
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 5   0x109ddb3b4 void IPC::callMemberFunction<WebKit::NetworkProcessProxy, void (WebKit::NetworkProcessProxy::*)(), std::__1::tuple<>, std::make_index_sequence<0ul> >(std::__1::tuple<>&&, WebKit::NetworkProcessProxy*, void (WebKit::NetworkProcessProxy::*)())
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 6   0x109dda5e0 void IPC::handleMessage<Messages::NetworkProcessProxy::DidCancelProcessSuspension, WebKit::NetworkProcessProxy, void (WebKit::NetworkProcessProxy::*)()>(IPC::MessageDecoder&, WebKit::NetworkProcessProxy*, void (WebKit::NetworkProcessProxy::*)())
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 7   0x109dd9cc0 WebKit::NetworkProcessProxy::didReceiveNetworkProcessProxyMessage(IPC::Connection&, IPC::MessageDecoder&)
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 8   0x109dd43e0 WebKit::NetworkProcessProxy::didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&)
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 9   0x109dd4418 non-virtual thunk to WebKit::NetworkProcessProxy::didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&)
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 10  0x109bfe194 IPC::Connection::dispatchMessage(IPC::MessageDecoder&)
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 11  0x109bf83fc IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::MessageDecoder, std::__1::default_delete<IPC::MessageDecoder> >)
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 12  0x109bfe554 IPC::Connection::dispatchOneMessage()
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 13  0x109c08c98 IPC::Connection::enqueueIncomingMessage(std::__1::unique_ptr<IPC::MessageDecoder, std::__1::default_delete<IPC::MessageDecoder> >)::$_10::operator()() const
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 14  0x109c08c70 void std::__1::__invoke_void_return_wrapper<void>::__call<IPC::Connection::enqueueIncomingMessage(std::__1::unique_ptr<IPC::MessageDecoder, std::__1::default_delete<IPC::MessageDecoder> >)::$_10&>(IPC::Connection::enqueueIncomingMessage(std::__1::unique_ptr<IPC::MessageDecoder, std::__1::default_delete<IPC::MessageDecoder> >)::$_10&&&)
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 15  0x109c08a4c std::__1::__function::__func<IPC::Connection::enqueueIncomingMessage(std::__1::unique_ptr<IPC::MessageDecoder, std::__1::default_delete<IPC::MessageDecoder> >)::$_10, std::__1::allocator<IPC::Connection::enqueueIncomingMessage(std::__1::unique_ptr<IPC::MessageDecoder, std::__1::default_delete<IPC::MessageDecoder> >)::$_10>, void ()>::operator()()
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 16  0x10076dd9c std::__1::function<void ()>::operator()() const
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 17  0x100c585d4 WTF::RunLoop::performWork()
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 18  0x100c597ec WTF::RunLoop::performWork(void*)
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 19  0x182ecfd6c <redacted>
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 20  0x182ecf800 <redacted>
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 21  0x182ecd500 <redacted>
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 22  0x182dfd280 CFRunLoopRunSpecific
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 23  0x18e5000cc GSEventRunModal
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 24  0x18862ee4c UIApplicationMain
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 25  0x1000073b4
Jul 18 13:29:44 iPhone MobileSafari[1517] <Notice>: 26  0x198e6a8b8 <redacted>

[Daniel Bates]

Created attachment 257124 [details]
Patch

[Radar WebKit Bug Importer]

<rdar://problem/21906759>

[Chris Dumez]

Comment on attachment 257124 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=257124&action=review

r=me

> Source/WebKit2/NetworkProcess/NetworkProcess.cpp:525
> +    // we do not because we have nothing to cancel. NetworkProcessProxy::DidCancelProcessSuspension should

nit: I think saying that we are not cancellable because prepareToSuspend() sends back the ProcessReadyToSuspend IPC message synchronously would be clearer.

[Daniel Bates]

(In reply to comment #3)
> > Source/WebKit2/NetworkProcess/NetworkProcess.cpp:525
> > +    // we do not because we have nothing to cancel. NetworkProcessProxy::DidCancelProcessSuspension should
> 
> nit: I think saying that we are not cancellable because prepareToSuspend()
> sends back the ProcessReadyToSuspend IPC message synchronously would be
> clearer.

Notice that the IPC message ProcessReadyToSuspend is sent asynchronously. I understand what you are trying to convey by using the word "synchronously" - the network process already replied to the NetworkProcess::PrepareToSuspend message with a NetworkProcessProxy::ProcessReadyToSuspend message and hence should not reply again with a NetworkProcessProxy::DidCancelProcessSuspension.

I will update the comment in this function to read to help clarify :

Although it is tempting to send a NetworkProcessProxy::DidCancelProcessSuspension message from here we do not because prepareToSuspend() already replied with a NetworkProcessProxy::ProcessReadyToSuspend message. NetworkProcessProxy::DidCancelProcessSuspension should only be sent if and only if we have not replied to a NetworkProcess::PrepareToSuspend message with a NetworkProcessProxy::ProcessReadyToSuspend message.

[Daniel Bates]

(In reply to comment #4)
> I will update the comment in this function to read to help clarify :

I meant to write:

I will update the comment in this function to help clarify why we do not send a NetworkProcessProxy::DidCancelProcessSuspension message.

[Daniel Bates]

Committed r187124: <http://trac.webkit.org/changeset/187124>