RESOLVED FIXED 159521
Add always-on logging for downloads
https://bugs.webkit.org/show_bug.cgi?id=159521
Summary Add always-on logging for downloads
Keith Rollin
Reported 2016-07-07 11:35:51 PDT
Add Logging 2.0 support for downloads to be able to diagnose issues like <rdar://problem/26444360>
Attachments
Patch (8.02 KB, patch)
2016-07-07 14:02 PDT, Keith Rollin
no flags
Patch (7.42 KB, patch)
2016-07-07 15:09 PDT, Keith Rollin
no flags
Patch (7.36 KB, patch)
2016-07-07 16:06 PDT, Keith Rollin
no flags
Patch (7.54 KB, patch)
2016-07-07 17:08 PDT, Keith Rollin
no flags
Keith Rollin
Comment 1 2016-07-07 11:36:29 PDT
Keith Rollin
Comment 2 2016-07-07 14:02:22 PDT
Chris Dumez
Comment 3 2016-07-07 14:04:43 PDT
Comment on attachment 283047 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=283047&action=review > Source/WebKit2/ChangeLog:13 > + Note that this logging only tracks WebKit-initiated downloading. It TMI
Chris Dumez
Comment 4 2016-07-07 14:06:56 PDT
Comment on attachment 283047 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=283047&action=review > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:44 > +#if USE(NETWORK_SESSION) && PLATFORM(COCOA) Do we really need this? What would prevent other non NetworkSession code to use those macros for e.g.? > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:95 > +#if USE(NETWORK_SESSION) && PLATFORM(COCOA) Is this really needed? > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:104 > +#if USE(NETWORK_SESSION) && PLATFORM(COCOA) Is this really needed? > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:146 > +#if USE(NETWORK_SESSION) && PLATFORM(COCOA) Is this really needed? > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:164 > +#if USE(NETWORK_SESSION) && PLATFORM(COCOA) Is this really needed? > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:180 > +#if USE(NETWORK_SESSION) && PLATFORM(COCOA) Is this really needed? > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:203 > +#if USE(NETWORK_SESSION) && PLATFORM(COCOA) Is this really needed?
Keith Rollin
Comment 5 2016-07-07 14:45:10 PDT
(In reply to comment #4) > Comment on attachment 283047 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=283047&action=review > > > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:44 > > +#if USE(NETWORK_SESSION) && PLATFORM(COCOA) > > Do we really need this? What would prevent other non NetworkSession code to > use those macros for e.g.? The logging macros reference isAlwaysOnLoggingAllowed(). That function looks at the associated sessionID to see if the session is private or not. That sessionID is available only in the "USE(NETWORK_SESSION) && PLATFORM(COCOA)" branches of code. I suppose it could tweak things around another way. I could change isAlwaysOnLoggingAllowed to always return some hard-coded bool (true or false, it probably doesn't matter) rather than something that references m_sessionID in the non-"USE(NETWORK_SESSION) && PLATFORM(COCOA)" case.
Chris Dumez
Comment 6 2016-07-07 14:47:36 PDT
Comment on attachment 283047 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=283047&action=review >>> Source/WebKit2/NetworkProcess/Downloads/Download.cpp:44 >>> +#if USE(NETWORK_SESSION) && PLATFORM(COCOA) >> >> Do we really need this? What would prevent other non NetworkSession code to use those macros for e.g.? > > The logging macros reference isAlwaysOnLoggingAllowed(). That function looks at the associated sessionID to see if the session is private or not. That sessionID is available only in the "USE(NETWORK_SESSION) && PLATFORM(COCOA)" branches of code. > > I suppose it could tweak things around another way. I could change isAlwaysOnLoggingAllowed to always return some hard-coded bool (true or false, it probably doesn't matter) rather than something that references m_sessionID in the non-"USE(NETWORK_SESSION) && PLATFORM(COCOA)" case. Or maybe have the DOWNLOAD_LOG_ALWAYS*() macros be no-ops for other platforms so that we don't need to #ifdef at every call site.
Keith Rollin
Comment 7 2016-07-07 15:09:17 PDT
Keith Rollin
Comment 8 2016-07-07 16:06:49 PDT
Chris Dumez
Comment 9 2016-07-07 16:49:40 PDT
Comment on attachment 283080 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=283080&action=review This will require WK2 owner review but here is my informal review. > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:45 > +#define DOWNLOAD_LOG_ALWAYS_ERROR(...) LOG_ALWAYS_ERROR(isAlwaysOnLoggingAllowed(), __VA_ARGS__) You're not using this one? > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:101 > + DOWNLOAD_LOG_ALWAYS("Download task (%llu) received bytes", downloadID().downloadID()); Received *first* bytes ? Or "started receiving data" ? > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:102 > + m_receivedData = true; As per coding style, Boolean variables need a prefix. In this case, I suggest "hasReceivedData" > Source/WebKit2/NetworkProcess/Downloads/Download.h:150 > + WebCore::SessionID m_sessionID; Shouldn't this be in the COCOA && NETWORK_SESSION block? > Source/WebKit2/NetworkProcess/Downloads/Download.h:152 > + bool m_receivedData = false; I think we usually use the { false } syntax.
Keith Rollin
Comment 10 2016-07-07 16:56:08 PDT
(In reply to comment #9) > Comment on attachment 283080 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=283080&action=review > > This will require WK2 owner review but here is my informal review. > > > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:45 > > +#define DOWNLOAD_LOG_ALWAYS_ERROR(...) LOG_ALWAYS_ERROR(isAlwaysOnLoggingAllowed(), __VA_ARGS__) > > You're not using this one? Not this time. I've generally added them in pairs for consistency. And so people can assume that if one is there, so is the other. > > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:101 > > + DOWNLOAD_LOG_ALWAYS("Download task (%llu) received bytes", downloadID().downloadID()); > > Received *first* bytes ? Or "started receiving data" ? OK. > > Source/WebKit2/NetworkProcess/Downloads/Download.cpp:102 > > + m_receivedData = true; > > As per coding style, Boolean variables need a prefix. In this case, I > suggest "hasReceivedData" OK. > > Source/WebKit2/NetworkProcess/Downloads/Download.h:150 > > + WebCore::SessionID m_sessionID; > > Shouldn't this be in the COCOA && NETWORK_SESSION block? You seemed to be encouraging the reduction of conditional compilation, so I didn't add a block here. > > Source/WebKit2/NetworkProcess/Downloads/Download.h:152 > > + bool m_receivedData = false; > > I think we usually use the { false } syntax. OK.
Chris Dumez
Comment 11 2016-07-07 16:57:06 PDT
Comment on attachment 283080 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=283080&action=review >>> Source/WebKit2/NetworkProcess/Downloads/Download.h:150 >>> + WebCore::SessionID m_sessionID; >> >> Shouldn't this be in the COCOA && NETWORK_SESSION block? > > You seemed to be encouraging the reduction of conditional compilation, so I didn't add a block here. But... The block is already there above.
Keith Rollin
Comment 12 2016-07-07 17:06:35 PDT
Yeah, but I didn't want to add to the list of things people had to think about. "Hrm. I don't remember...is m_sessionID available in this context or not?". On the other hand, including an m_sessionID that is meaningful only some of the time is probably not a good idea, either. Overall, I guess the best solution is to figure out how to get rid of these conditionals in the first place. :-) In the meantime, I'll put m_sessionID back up in the conditional block.
Keith Rollin
Comment 13 2016-07-07 17:08:16 PDT
Alex Christensen
Comment 14 2016-07-07 19:48:38 PDT
Comment on attachment 283092 [details] Patch platform differences in networking and downloading code are going to be around for a long time.
WebKit Commit Bot
Comment 15 2016-07-08 10:55:22 PDT
Comment on attachment 283092 [details] Patch Clearing flags on attachment: 283092 Committed r202993: <http://trac.webkit.org/changeset/202993>
WebKit Commit Bot
Comment 16 2016-07-08 10:55:28 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.