Crash in Connection::isValid when called in response to VisitedLinksProvider::pendingVisitedLinksTimerFired after WebProcessPRoxy::didClose was already called

[Jessie Berlin]

We should create a WebContext::webProcessDidClose method, have it stop the timer, and call that from WebContext::didClose.

[Jessie Berlin]

Created attachment 71594 [details]
Add WebContext::proccessDidClose and stop the visited links timer there

[Jessie Berlin]

<rdar://problem/8580585>

[Anders Carlsson]

Comment on attachment 71594 [details]
Add WebContext::proccessDidClose and stop the visited links timer there

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

Looks great otherwise, r=me!

> WebKit2/UIProcess/WebProcessProxy.cpp:420
> +    m_context->processDidClose(this);

You should call processDidClose before the call to WebProcessManager::processDidClose because calling it might delete the WebProcessProxy object.

[Jessie Berlin]

(In reply to comment #3)
> (From update of attachment 71594 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=71594&action=review
> 
> Looks great otherwise, r=me!
> 
> > WebKit2/UIProcess/WebProcessProxy.cpp:420
> > +    m_context->processDidClose(this);
> 
> You should call processDidClose before the call to WebProcessManager::processDidClose because calling it might delete the WebProcessProxy object.

Done.

Thanks for the review!

[Jessie Berlin]

Comment on attachment 71594 [details]
Add WebContext::proccessDidClose and stop the visited links timer there

Committed in r70346
http://trac.webkit.org/changeset/70346

[Adam Roben (:aroben)]

Is there any way to make a test for this?

[Jessie Berlin]

(In reply to comment #6)
> Is there any way to make a test for this?

I don't think so at the moment. The case in which we are currently seeing this happen is not necessarily caused by the WebProcess crashing - more has to do with the timing of the WebProcess ending which is a bit hard to control.