ResourceLoadTiming should not be assumed to be available in ResourceTiming.

third_party/WebKit/Source/core/timing/PerformanceResourceTiming.cpp

Index: third_party/WebKit/Source/core/timing/PerformanceResourceTiming.cpp
diff --git a/third_party/WebKit/Source/core/timing/PerformanceResourceTiming.cpp b/third_party/WebKit/Source/core/timing/PerformanceResourceTiming.cpp
index 3353a97ef0b3410e2f53f5045d7ba8618890336b..3b4eb069a43bfc7f24e1dee2611ce50a9e2dbc66 100644
--- a/third_party/WebKit/Source/core/timing/PerformanceResourceTiming.cpp
+++ b/third_party/WebKit/Source/core/timing/PerformanceResourceTiming.cpp
@@ -136,10 +136,10 @@ DOMHighResTimeStamp PerformanceResourceTiming::redirectEnd() const {
 }
 
 DOMHighResTimeStamp PerformanceResourceTiming::fetchStart() const {
+  if (!m_timing)
+    return PerformanceEntry::startTime();
+
   if (m_lastRedirectEndTime) {
-    // FIXME: ASSERT(m_timing) should be in constructor once timeticks of
-    // AppCache is exposed from chrome network stack, crbug/251100

[panicker, 2017/03/08 23:16:51]

This assumption was apparently fine in Jun 2013 (in this patch:
https://chromiumcodereview.appspot.com/16950017/) when the code was authored,
but has since become invalid. The crashes started in Nov 2015.
All other dereferences of m_timing check for null, except for this one.

-    ASSERT(m_timing);
     return PerformanceBase::monotonicTimeToDOMHighResTimeStamp(
         m_timeOrigin, m_timing->requestTime());
   }