RESOLVED FIXED 159001
Add logging related to process assertions to help debug process suspension issues
https://bugs.webkit.org/show_bug.cgi?id=159001
Summary Add logging related to process assertions to help debug process suspension is...
Chris Dumez
Reported 2016-06-21 15:01:54 PDT
Add logging related to process assertions to help debug process suspension issues.
Attachments
Patch (7.69 KB, patch)
2016-06-21 15:03 PDT, Chris Dumez
no flags
Patch (9.67 KB, patch)
2016-06-21 16:14 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2016-06-21 15:03:19 PDT
Keith Rollin
Comment 2 2016-06-21 15:45:08 PDT
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
Comment 3 2016-06-21 15:49:37 PDT
(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
Comment 4 2016-06-21 16:14:38 PDT
Chris Dumez
Comment 5 2016-06-22 08:48:44 PDT
Chris Dumez
Comment 6 2016-06-22 10:00:35 PDT
Comment on attachment 281792 [details] Patch Clearing flags on attachment: 281792 Committed r202331: <http://trac.webkit.org/changeset/202331>
Chris Dumez
Comment 7 2016-06-22 10:00:40 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.