Issue metadata
Sign in to add a comment
|
Check failed in WebGL tests: current_allocation_point FATAL:heap_page.cc(1558)] Check failed: !current_allocation_point || (PageFromObject(current_allocation_point) != this). |
||||||||||||||||||||||||
Issue descriptionMight be a very recent regression. Seeing this on my ANGLE CLs. Could not possibly be the CL's fault. See: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win_angle_rel_ng/1804 Backtrace: base::debug::StackTrace::StackTrace [0x6745D070+32] base::debug::StackTrace::StackTrace [0x6745C86D+13] logging::LogMessage::~LogMessage [0x67471FF3+83] blink::NormalPage::VerifyObjectStartBitmapIsConsistentWithPayload [0x6727150E+234] blink::NormalPage::Sweep [0x6727386C+496] blink::BaseArena::SweepUnsweptPage [0x6727066D+17] blink::BaseArena::LazySweepWithDeadline [0x672707BD+289] blink::ThreadHeap::AdvanceLazySweep [0x6726B1F9+125] blink::ThreadState::PerformIdleLazySweep [0x6727AAE5+279] base::internal::Invoker<base::internal::BindState<void (__thiscall blink::ThreadState::*)(base::TimeTicks),WTF::UnretainedWrapper<blink::ThreadState> >,void __cdecl(base::TimeTicks)>::RunOnce [0x6727EDF0+20] base::OnceCallback<void __cdecl(base::TimeTicks)>::Run [0x6727EE33+65] WTF::ThreadCheckingCallbackWrapper<base::OnceCallback<void __cdecl(base::TimeTicks)>,void __cdecl(base::TimeTicks)>::Run [0x6727EDC3+107] base::internal::Invoker<base::internal::BindState<void (__thiscall blink::ThreadState::*)(base::TimeTicks),WTF::UnretainedWrapper<blink::ThreadState> >,void __cdecl(base::TimeTicks)>::RunOnce [0x6727EDF0+20] base::OnceCallback<void __cdecl(base::TimeTicks)>::Run [0x6727EE33+65] blink::scheduler::NonMainThreadSchedulerImpl::RunIdleTask [0x672E703C+20] base::internal::FunctorTraits<void (__cdecl*)(scoped_refptr<blink::internal::IdleRequestCallbackWrapper>,base::TimeTicks),void>::Invoke<void (__cdecl*)(scoped_refptr<blink::internal::IdleRequestCallbackWrapper>,base::TimeTicks),scoped_refptr<blink::intern [0x672EA4BA+54] base::internal::Invoker<base::internal::BindState<void (__cdecl*)(scoped_refptr<blink::internal::IdleRequestCallbackWrapper>,base::TimeTicks),scoped_refptr<blink::internal::IdleRequestCallbackWrapper> >,void __cdecl(base::TimeTicks)>::RunOnce [0x672EA47E+22] base::OnceCallback<void __cdecl(base::TimeTicks)>::Run [0x6727EE33+65] blink::scheduler::SingleThreadIdleTaskRunner::RunTask [0x672CCC65+91] base::internal::FunctorTraits<void (__thiscall blink::scheduler::SingleThreadIdleTaskRunner::*)(base::OnceCallback<void __cdecl(base::TimeTicks)>),void>::Invoke<void (__thiscall blink::scheduler::SingleThreadIdleTaskRunner::*)(base::OnceCallback<void __cd [0x672CD1FF+53] base::internal::Invoker<base::internal::BindState<void (__thiscall blink::scheduler::SingleThreadIdleTaskRunner::*)(base::OnceCallback<void __cdecl(base::TimeTicks)>),base::WeakPtr<blink::scheduler::SingleThreadIdleTaskRunner>,base::OnceCallback<void __cd [0x672CD1B9+79] base::debug::TaskAnnotator::RunTask [0x6826F212+306] base::sequence_manager::internal::ThreadControllerImpl::DoWork [0x679B6AF9+713] base::internal::Invoker<base::internal::BindState<void (__thiscall base::sequence_manager::internal::ThreadControllerImpl::*)(enum base::sequence_manager::internal::ThreadControllerImpl::WorkType),base::WeakPtr<base::sequence_manager::internal::ThreadCont [0x677F40BE+158] base::debug::TaskAnnotator::RunTask [0x6826F212+306] base::internal::IncomingTaskQueue::RunTask [0x679A598C+108] Will monitor the bots.
,
Jul 5
CC'ing a few folks who have done work on Oilpan recently (based on Git logs). Tracking this down is urgent; we shouldn't leave this sort of brokenness on the tree. Good regression range Jamie; let's dig further and see what it could be.
,
Jul 5
Would be great if FindIt would work for this use case where random tests become flaky. CC'ing a couple of folks working on FindIt.
,
Jul 5
,
Jul 5
I don't think it was smaier's https://chromium-review.googlesource.com/1126160 . That CL was Android-only.
,
Jul 5
My best guess is: Loader: Introduce FetchSettingsClientObject in BaseFetchContext https://chromium-review.googlesource.com/1124209 Reverting proactively to see if it clears up the failures.
,
Jul 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4b1182bd125001adecd65ae792aa7b587cea99b7 commit 4b1182bd125001adecd65ae792aa7b587cea99b7 Author: Kenneth Russell <kbr@chromium.org> Date: Thu Jul 05 18:56:47 2018 Revert "Loader: Introduce FetchSettingsClientObject in BaseFetchContext" This reverts commit 8326c318be0646674658e241e8765afe7d63eee7. Reason for revert: believe this may be the cause of random crashes in the WebGL 2.0 conformance tests per http://crbug.com/860517 . Bug: 860517 Original change's description: > Loader: Introduce FetchSettingsClientObject in BaseFetchContext > > <Overview> > > This CL introduces FetchSettingsClientObject in BaseFetchContext and replaces > some functions of BaseFetchContext with that. This makes the scope of > responsibilities of BaseFetchContext clearer. > > Also, this is a preparation for separating ResourceFetcher for main resource > request and subresource requests for workers and worklets. The main resource > request needs a snapshot of the fetch client settings object of the parent > execution context, while the subresource requests need up-to-date values of the > fetch client settings object of the worker / worklet execution context. This > change enables a subsequent CL easily to inject the fetch client settings object > from externals of WorkerFetchContext. > > <Technical details> > > - This CL introduces FetchSettingsClientObject interface and > FetchSettingsClientObjectImpl. Also, this makes > FetchSettingsClientObjectSnapshot inherit the interface so that > BaseFetchContext doesn't have to take care of an actual implementation. > - FrameFetchContext has the FrozenState concept that is used for keeping states > even after the frame is detached. Similarly, this CL makes FrameFetchContext > creates a new instance of FetchSettingsClientObjectSnapshot on frame detach, > and replace the current |fetch_client_settings_object_| with that. > > Bug: 845285 > Change-Id: I29e2dbac640507e6c128da932737cacb7a844920 > Reviewed-on: https://chromium-review.googlesource.com/1124209 > Commit-Queue: Hiroki Nakagawa <nhiroki@chromium.org> > Reviewed-by: Kouhei Ueno <kouhei@chromium.org> > Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> > Cr-Commit-Position: refs/heads/master@{#572805} TBR=kinuko@chromium.org,hiroshige@chromium.org,kouhei@chromium.org,nhiroki@chromium.org Change-Id: I807d2256b0054cd06ae931392cd192c3a50bb850 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 845285 Reviewed-on: https://chromium-review.googlesource.com/1127420 Reviewed-by: Kenneth Russell <kbr@chromium.org> Commit-Queue: Kenneth Russell <kbr@chromium.org> Cr-Commit-Position: refs/heads/master@{#572834} [modify] https://crrev.com/4b1182bd125001adecd65ae792aa7b587cea99b7/third_party/blink/renderer/core/loader/base_fetch_context.cc [modify] https://crrev.com/4b1182bd125001adecd65ae792aa7b587cea99b7/third_party/blink/renderer/core/loader/base_fetch_context.h [modify] https://crrev.com/4b1182bd125001adecd65ae792aa7b587cea99b7/third_party/blink/renderer/core/loader/base_fetch_context_test.cc [modify] https://crrev.com/4b1182bd125001adecd65ae792aa7b587cea99b7/third_party/blink/renderer/core/loader/frame_fetch_context.cc [modify] https://crrev.com/4b1182bd125001adecd65ae792aa7b587cea99b7/third_party/blink/renderer/core/loader/frame_fetch_context.h [modify] https://crrev.com/4b1182bd125001adecd65ae792aa7b587cea99b7/third_party/blink/renderer/core/loader/modulescript/module_tree_linker.cc [modify] https://crrev.com/4b1182bd125001adecd65ae792aa7b587cea99b7/third_party/blink/renderer/core/loader/worker_fetch_context.cc [modify] https://crrev.com/4b1182bd125001adecd65ae792aa7b587cea99b7/third_party/blink/renderer/core/loader/worker_fetch_context.h [modify] https://crrev.com/4b1182bd125001adecd65ae792aa7b587cea99b7/third_party/blink/renderer/core/script/BUILD.gn [delete] https://crrev.com/c92e44c00324be13288005dea74f3118979fcfd1/third_party/blink/renderer/core/script/fetch_client_settings_object.h [delete] https://crrev.com/c92e44c00324be13288005dea74f3118979fcfd1/third_party/blink/renderer/core/script/fetch_client_settings_object_impl.cc [delete] https://crrev.com/c92e44c00324be13288005dea74f3118979fcfd1/third_party/blink/renderer/core/script/fetch_client_settings_object_impl.h [modify] https://crrev.com/4b1182bd125001adecd65ae792aa7b587cea99b7/third_party/blink/renderer/core/script/fetch_client_settings_object_snapshot.h
,
Jul 5
Let's see whether the above revert clears up the failures. If it doesn't I'll reland it.
,
Jul 5
Need to watch this bot: https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Release%20%28NVIDIA%29 The build before the revert, which is currently running, is: https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Release%20%28NVIDIA%29/1616
,
Jul 5
,
Jul 5
There's evidence that this was the correct CL to revert. In this CL: https://chromium-review.googlesource.com/1127156 there was a flaky failure of webgl_conformance_tests here: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win7_chromium_rel_ng/31972 Last event: 1310.1b1c: Break instruction exception - code 80000003 (first/second chance not available) debugger time: Thu Jul 5 12:21:41.757 2018 (UTC - 7:00) ChildEBP RetAddr Args to Child 04d3d904 6c09e8af 6ea8ee64 00000616 0e34116d chrome_child!base::debug::BreakDebugger+0xc 04d3d924 6bcb23d7 071e5438 6ea8ee64 00000616 chrome_child!?Run@?$Invoker@U?$BindState@P6AXPBDHV?$BasicStringPiece@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@base@@1@Z$$V@internal@base@@$$A6AXPBDHV?$BasicStringPiece@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@3@1@Z@internal@base@@SAXPAVBindStateBase@23@PBDH$$QAV?$BasicStringPiece@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@3@2@Z+0x1f 04d3de58 6bab180e 04d3df38 6bab49de 5949efbc chrome_child!logging::LogMessage::~LogMessage+0x467 04d3df40 6bab3b6c 00000001 478401c0 5949effc chrome_child!blink::NormalPage::VerifyObjectStartBitmapIsConsistentWithPayload+0xea 04d3e030 6bab2d1b 6afeb1f1 00d3e088 00000008 chrome_child!blink::NormalPage::Sweep+0x1f0 04d3e108 6bab083e 00000050 00000051 04d3e1e8 chrome_child!blink::NormalPageArena::LazySweepPages+0x79 04d3e1e8 6bab3041 00000050 00000051 00000000 chrome_child!blink::BaseArena::LazySweep+0xa4 04d3e2c0 6bab31e7 00000050 00000051 00001b1c chrome_child!blink::NormalPageArena::OutOfLineAllocate+0xe9 04d3e3a0 6bac65d3 00000050 00000051 0000004c chrome_child!blink::NormalPageArena::AllocateObject+0x13d 04d3e480 6bb7f7c0 6f5db45c 00000048 00000003 chrome_child!blink::ThreadHeap::AllocateOnArenaIndex+0x11d 04d3e4a8 6c935684 00000048 00000000 0b5f8308 chrome_child!blink::ThreadHeap::Allocate<blink::ScriptWrappable>+0x54 04d3e574 6c930713 00000048 04d3e5b4 04d3e5b8 chrome_child!blink::VideoTrack::operator new+0x74 04d3e58c 6c930681 04d3e5b4 04d3e5bc 04d3e5b8 chrome_child!blink::VideoTrack::Create+0x13 04d3e688 6d448c35 04d3e6bc 04d3e6c0 00000003 chrome_child!blink::HTMLMediaElement::AddVideoTrack+0x291 04d3e794 6bc956f5 0de99aa0 22a64a7f 0b746138 chrome_child!media::WebMediaPlayerImpl::OnFFmpegMediaTracksUpdated+0x2b5 This tryjob ran at r572833. The above revert landed at r572834. It was retried here: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win7_chromium_rel_ng/32001 which ran at r572843, and passed.
,
Jul 5
Issue 860551 has been merged into this issue.
,
Jul 5
,
Jul 5
The first build containing the revert was green: https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Release%20%28NVIDIA%29/1617 and the two builds beforehand had several random failures in this test suite: https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Release%20%28NVIDIA%29/1616 https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Release%20%28NVIDIA%29/1615 The above CL was clearly the cause of the crashes. nhiroki@, assigning to you to debug what happened. Please solve this before attempting to re-land. Thanks.
,
Jul 6
Thank you for debugging and reverting my CL. I'll make sure the reland patch doesn't contain the crashes.
,
Jul 6
Thanks Ken for your assistance with this.
,
Jul 6
This could be an issue in Oilpan's GC. keishi@ is now investigating the possibility: https://chromium-review.googlesource.com/c/chromium/src/+/1127202 P1->P2 because the culprit CL was already reverted.
,
Jul 10
keishi@ fixed the Oilpan's GC bug in issue 861624. Thank you! |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by jmad...@chromium.org
, Jul 5