Bug 159001 – Add logging related to process assertions to help debug process suspension issues

• Component: WebKit2
• Status: RESOLVED FIXED

[Chris Dumez]

Add logging related to process assertions to help debug process suspension issues.

[Chris Dumez]

Created attachment 281781 [details]
Patch

[Keith Rollin]

Some questions:

* How much logging does this emit? When opening a page? When closing a page? When putting a page in the background? When putting a page in the foreground? In short, will someone complain that there's too much logging?

* In the lambdas that call a completion handler, I'd put the logging before the call of the completion handler. If there's logging in the completion handlers, I think the result would read better.

* The common aspect of the added logging is that it involves calls to backgroundActivityToken and foregroundActivityToken. There are other places where these functions are invoked -- should they be flagged, too?

* Are any of these call sites session specific? I do see that WebPageProxy, for example, has a sessionID. If so, should the logging at those sites be suppressed for private sessions?

[Chris Dumez]

(In reply to comment #2)
> Some questions:
> 
> * How much logging does this emit? When opening a page? When closing a page?
> When putting a page in the background? When putting a page in the
> foreground? In short, will someone complain that there's too much logging?

No, it logs on very specific operations (view visibility state change, load started / ended). It does very little logging.

> 
> * In the lambdas that call a completion handler, I'd put the logging before
> the call of the completion handler. If there's logging in the completion
> handlers, I think the result would read better.

The assertion really gets released then the lambda gets destroyed (because the token is captured in the lambda by value). Therefore, the *last* line in the lambda is really the best place to log that the assertion was released I believe.

> 
> * The common aspect of the added logging is that it involves calls to
> backgroundActivityToken and foregroundActivityToken. There are other places
> where these functions are invoked -- should they be flagged, too?

I focused on the most important ones for now. I will add more if this turns out to be insufficient.

> 
> * Are any of these call sites session specific? I do see that WebPageProxy,
> for example, has a sessionID. If so, should the logging at those sites be
> suppressed for private sessions?

I'll double check, I thought all the code paths I altered weren't specific to a particular session but I could be wrong.

[Chris Dumez]

Created attachment 281792 [details]
Patch

[Chris Dumez]

rdar://problem/17665473

[Chris Dumez]

Comment on attachment 281792 [details]
Patch

Clearing flags on attachment: 281792

Committed r202331: <http://trac.webkit.org/changeset/202331>

[Chris Dumez]

All reviewed patches have been landed.  Closing bug.