Bug 158266

Summary: Fix null dereferencing in ResourceTimingInformation::addResourceTiming
Product: WebKit Reporter: Alex Christensen <achristensen>
Component: New BugsAssignee: Alex Christensen <achristensen>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, cdumez, commit-queue, japhet, ryanhaddad
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Description Alex Christensen 2016-06-01 11:38:57 PDT
Fix null dereferencing in ResourceTimingInformation::addResourceTiming
Comment 1 Alex Christensen 2016-06-01 11:43:19 PDT
Created attachment 280253 [details]
Patch
Comment 2 Brady Eidson 2016-06-01 11:45:58 PDT
Comment on attachment 280253 [details]
Patch

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

How was this noticed? How does it reproduce? How can we test it?

> Source/WebCore/ChangeLog:9
> +        Reviewed by NOBODY (OOPS!).
> +
> +        * loader/ResourceTimingInformation.cpp:

There's an expected WebCore/ChangeLog line missing here...!
Comment 3 Alex Christensen 2016-06-01 11:50:14 PDT
Created attachment 280255 [details]
Patch
Comment 4 Chris Dumez 2016-06-01 11:53:36 PDT
Comment on attachment 280255 [details]
Patch

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

> Source/WebCore/loader/ResourceTimingInformation.cpp:46
> +        auto initiatorIt = m_initiatorMap.find(resource);

Considering it does nothing when document is null, shouldn't we update the parameter to be a Document& document and do a null check at the call site if needed?
Comment 5 Alexey Proskuryakov 2016-06-01 11:54:01 PDT
Comment on attachment 280255 [details]
Patch

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

> Source/WebCore/ChangeLog:9
> +        This would crash sometimes in http/tests/security/cross-frame-access-custom.html

Given that it's a flaky crash, is it actually correct to fix it with a null check? What will the observable failure be when we bail out early?
Comment 6 Alex Christensen 2016-06-01 12:04:18 PDT
Created attachment 280257 [details]
Patch
Comment 7 Alex Christensen 2016-06-01 12:09:03 PDT
(In reply to comment #5)
> Comment on attachment 280255 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=280255&action=review
> 
> > Source/WebCore/ChangeLog:9
> > +        This would crash sometimes in http/tests/security/cross-frame-access-custom.html
> 
> Given that it's a flaky crash, is it actually correct to fix it with a null
> check? What will the observable failure be when we bail out early?
If there's no document, then the performance entry simply won't be recorded.  I think this is correct.

Chris's suggestion makes this patch look and feel much better.  We were really assuming CachedResourceLoader::document always returned non-null, which was a bad assumption.  There are other similar checks in CachedResourceLoader.cpp.
Comment 8 Chris Dumez 2016-06-01 12:41:30 PDT
Comment on attachment 280257 [details]
Patch

Seems reasonable.
Comment 9 WebKit Commit Bot 2016-06-01 13:14:04 PDT
Comment on attachment 280257 [details]
Patch

Clearing flags on attachment: 280257

Committed r201565: <http://trac.webkit.org/changeset/201565>
Comment 10 WebKit Commit Bot 2016-06-01 13:14:09 PDT
All reviewed patches have been landed.  Closing bug.