DCHECKs in FATAL:navigation_predictor.cc(241) |
|||
Issue descriptionThis recently re-enabled DCHECK is causing flaky test failures in telemetry_perf_unittests -- benchmarks.system_health_smoke_test.SystemHealthBenchmarkSmokeTest.system_health.memory_mobile/load:news:washingtonpost. https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-marshmallow-arm64-rel/103947 """ [FATAL:navigation_predictor.cc(241)] Check failed: 1.0 >= prev_metric->ratio_area (1 vs. 1.13474) Stack Trace: RELADDR FUNCTION FILE:LINE 0000000003e0ce1b logging::LogMessage::~LogMessage() ??:0:0 0000000003c1120f NavigationPredictor::MergeMetricsSameTargetUrl(std::__ndk1::vector<mojo::StructPtr<blink::mojom::AnchorElementMetrics>, std::__ndk1::allocator<mojo::StructPtr<blink::mojom::AnchorElementMetrics> > >*) const ??:0:0 0000000003c11837 NavigationPredictor::ReportAnchorElementMetricsOnLoad(std::__ndk1::vector<mojo::StructPtr<blink::mojom::AnchorElementMetrics>, std::__ndk1::allocator<mojo::StructPtr<blink::mojom::AnchorElementMetrics> > >) ??:0:0 000000000234d5c3 blink::mojom::AnchorElementMetricsHostStubDispatch::Accept(blink::mojom::AnchorElementMetricsHost*, mojo::Message*) ??:0:0 0000000003ef3423 mojo::InterfaceEndpointClient::HandleValidatedMessage(mojo::Message*) ??:0:0 0000000003ef3113 mojo::FilterChain::Accept(mojo::Message*) ??:0:0 0000000003ef416f mojo::InterfaceEndpointClient::HandleIncomingMessage(mojo::Message*) ??:0:0 0000000003ef748b mojo::internal::MultiplexRouter::ProcessIncomingMessage(mojo::internal::MultiplexRouter::MessageWrapper*, mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) ??:0:0 0000000003ef703b mojo::internal::MultiplexRouter::Accept(mojo::Message*) ??:0:0 0000000003ef3113 mojo::FilterChain::Accept(mojo::Message*) ??:0:0 0000000003ef0367 mojo::Connector::ReadSingleMessage(unsigned int*) ??:0:0 0000000003ef0a37 mojo::Connector::ReadAllAvailableMessages() ??:0:0 0000000003ef08bb mojo::Connector::OnHandleReadyInternal(unsigned int) ??:0:0 000000000202a3f7 void base::internal::Invoker<base::internal::BindState<void (net::HostResolverImpl::LegacyRequestImpl::*)(int), base::internal::UnretainedWrapper<net::HostResolverImpl::LegacyRequestImpl> >, void (int)>::RunImpl<void (net::HostResolverImpl::LegacyRequestImpl::*)(int), std::__ndk1::tuple<base::internal::UnretainedWrapper<net::HostResolverImpl::LegacyRequestImpl> >, 0ul>(void (net::HostResolverImpl::LegacyRequestImpl::*&&)(int), std::__ndk1::tuple<base::internal::UnretainedWrapper<net::HostResolverImpl::LegacyRequestImpl> >&&, std::__ndk1::integer_sequence<unsigned long, 0ul>, int&&) ??:0:0 000000000202a3cb base::internal::Invoker<base::internal::BindState<void (net::HostResolverImpl::LegacyRequestImpl::*)(int), base::internal::UnretainedWrapper<net::HostResolverImpl::LegacyRequestImpl> >, void (int)>::RunOnce(base::internal::BindStateBase*, int) ??:0:0 0000000003f06927 mojo::SimpleWatcher::OnHandleReady(int, unsigned int, mojo::HandleSignalsState const&) ??:0:0 0000000003dfcd5f base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) ??:0:0 0000000003e17acb base::MessageLoop::RunTask(base::PendingTask*) ??:0:0 0000000003e17deb base::MessageLoop::DoWork() ??:0:0 0000000003e1b27f base::MessagePumpForUI::OnNonDelayedLooperCallback() ??:0:0 0000000003e1af0f base::(anonymous namespace)::NonDelayedLooperCallback(int, int, void*) ??:0:0 000000000001aef3 <UNKNOWN> /system/lib64/libutils.so 000000000001b157 <UNKNOWN> /system/lib64/libutils.so 00000000000a5017 <UNKNOWN> /system/lib64/libandroid_runtime.so 0000000001ed883f <UNKNOWN> /data/dalvik-cache/arm64/system@framework@boot.oat """
,
Oct 11
,
Oct 11
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/36955f04ab6bcb80859005bb76def5d61d1e8d63 commit 36955f04ab6bcb80859005bb76def5d61d1e8d63 Author: Tarun Bansal <tbansal@chromium.org> Date: Thu Oct 11 19:03:42 2018 Reenable DCHECKs in navigation predictor Some of the DCHECKs were disabled due to a bug which was causing same anchor element to be reported multiple times to the browser process. Now, since that bug has been fixed, we can reenable some of the DCHECKs in navigation predictor which ensure that the size occupied by any target HREF (after aggregating across all anchor elements that point to the same target) does not exceed 1.0. Bug: 894092 Change-Id: Iec003a857e8b990bcc01f522e49ed8cdd6191137 Reviewed-on: https://chromium-review.googlesource.com/c/1277372 Commit-Queue: Tarun Bansal <tbansal@chromium.org> Reviewed-by: Ryan Sturm <ryansturm@chromium.org> Cr-Commit-Position: refs/heads/master@{#598875} [modify] https://crrev.com/36955f04ab6bcb80859005bb76def5d61d1e8d63/chrome/browser/navigation_predictor/navigation_predictor.cc
,
Oct 11
|
|||
►
Sign in to add a comment |
|||
Comment 1 by tbansal@chromium.org
, Oct 11Status: Started (was: Assigned)