Summary: | Add logging related to process assertions to help debug process suspension issues | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||||
Component: | WebKit2 | Assignee: | Chris Dumez <cdumez> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | andersca, kling, koivisto, krollin, rniwa, sam | ||||||
Priority: | P2 | ||||||||
Version: | WebKit Nightly Build | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Chris Dumez
2016-06-21 15:01:54 PDT
Created attachment 281781 [details]
Patch
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? (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. Created attachment 281792 [details]
Patch
Comment on attachment 281792 [details] Patch Clearing flags on attachment: 281792 Committed r202331: <http://trac.webkit.org/changeset/202331> All reviewed patches have been landed. Closing bug. |