Issue metadata
Sign in to add a comment
|
V8_Fatal on Youtube TV automatic player
Reported by
joha...@opera.com,
Apr 5 2017
|
||||||||||||||||||||||||
Issue descriptionChrome Version: content_shell (commit 9f01b1a8c8342b49b40ca21ebeb111465793c03f) OS: Linux Ubuntu 16.04 x86_64 What steps will reproduce the problem? (1) load https://www.youtube.com/tv?loader=setshi in content_shell (2) wait ~27h for it to crash What is the expected result? Should keep running, no buildup in live v8 objects. What happens instead? After ~27h renderer used ~2G memory and hit this check in v8 and crashed, see output below: Fatal error in ../../v8/src/heap/mark-compact-inl.h, line 164 Check failed: not_done. # #0 0x7f313d70bd7b base::debug::StackTrace::StackTrace() #1 0x7f313d70aa7c base::debug::StackTrace::StackTrace() #2 0x7f3138044e17 gin::(anonymous namespace)::PrintStackTrace() #3 0x7f3129d0f63c V8_Fatal #4 0x7f31377f5931 v8::internal::LiveObjectIterator<>::Next() #5 0x7f31377f5134 v8::internal::MarkCompactCollector::Sweeper::RawSweep() #6 0x7f31377ebdd0 v8::internal::MarkCompactCollector::Sweeper::ParallelSweepPage() #7 0x7f31377ec065 v8::internal::MarkCompactCollector::Sweeper::ParallelSweepSpace() #8 0x7f31378001a3 v8::internal::MarkCompactCollector::Sweeper::SweeperTask::Run() #9 0x7f313802ffc5 ZN4base8internal13FunctorTraitsIMNS_5TimerEFvvEvE6InvokeIPS2_JEEEvS4_OT_DpOT0 #10 0x7f313802fee1 ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMNS_5TimerEFvvEJPS4_EEEvOT_DpOT0 #11 0x7f3138048a77 _ZN4base8internal7InvokerINS0_9BindStateIMN2v84TaskEFvvEJNS0_12OwnedWrapperIS4_EEEEEFvvEE7RunImplIRKS6_RKSt5tupleIJS8_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE #12 0x7f31380489bc _ZN4base8internal7InvokerINS0_9BindStateIMN2v84TaskEFvvEJNS0_12OwnedWrapperIS4_EEEEEFvvEE3RunEPNS0_13BindStateBaseE #13 0x7f313d7122ae _ZNO4base8CallbackIFvvELNS_8internal8CopyModeE0ELNS2_10RepeatModeE0EE3RunEv #14 0x7f313d9031aa base::(anonymous namespace)::WorkerThread::ThreadMain() #15 0x7f313d8dc2ba base::(anonymous namespace)::ThreadFunc() #16 0x7f3142d776ba start_thread #17 0x7f312f08a82d clone Received signal 4 ILL_ILLOPN 7f3129d11c32 #0 0x7f313d70bd7b base::debug::StackTrace::StackTrace() #1 0x7f313d70aa7c base::debug::StackTrace::StackTrace() #2 0x7f313d70b88f base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7f3142d81390 <unknown> #4 0x7f3129d11c32 v8::base::OS::Abort() #5 0x7f31377f5931 v8::internal::LiveObjectIterator<>::Next() #6 0x7f31377f5134 v8::internal::MarkCompactCollector::Sweeper::RawSweep() #7 0x7f31377ebdd0 v8::internal::MarkCompactCollector::Sweeper::ParallelSweepPage() #8 0x7f31377ec065 v8::internal::MarkCompactCollector::Sweeper::ParallelSweepSpace() #9 0x7f31378001a3 v8::internal::MarkCompactCollector::Sweeper::SweeperTask::Run() #10 0x7f313802ffc5 ZN4base8internal13FunctorTraitsIMNS_5TimerEFvvEvE6InvokeIPS2_JEEEvS4_OT_DpOT0 #11 0x7f313802fee1 ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMNS_5TimerEFvvEJPS4_EEEvOT_DpOT0 #12 0x7f3138048a77 _ZN4base8internal7InvokerINS0_9BindStateIMN2v84TaskEFvvEJNS0_12OwnedWrapperIS4_EEEEEFvvEE7RunImplIRKS6_RKSt5tupleIJS8_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE #13 0x7f31380489bc _ZN4base8internal7InvokerINS0_9BindStateIMN2v84TaskEFvvEJNS0_12OwnedWrapperIS4_EEEEEFvvEE3RunEPNS0_13BindStateBaseE #14 0x7f313d7122ae _ZNO4base8CallbackIFvvELNS_8internal8CopyModeE0ELNS2_10RepeatModeE0EE3RunEv #15 0x7f313d9031aa base::(anonymous namespace)::WorkerThread::ThreadMain() #16 0x7f313d8dc2ba base::(anonymous namespace)::ThreadFunc() #17 0x7f3142d776ba start_thread #18 0x7f312f08a82d clone r8: 00007f312f349770 r9: 00007f30ed32a700 r10: 0000000000000000 r11: 0000000000000000 r12: 00007f312f348700 r13: 00007f30ed3296a0 r14: 00007f3137d7d08a r15: 00000000000000a4 di: 00007f312f348540 si: 00007f312f349770 bp: 00007f30ed329560 bx: 00007f3137dec59e dx: 0000000000000000 ax: 0000000000000000 cx: 14f9ee6c2a7b8200 sp: 00007f30ed329468 ip: 00007f3129d11c32 efl: 0000000000010202 cgf: 5f00000000000033 erf: 0000000000000000 trp: 0000000000000006 msk: 0000000000000000 cr2: 0000000000000000 [end of stack trace] Calling _exit(1). Core file will not be generated.
,
Apr 12 2017
trying to repro... will report back in ~27h
,
Apr 17 2017
mlippautz@ I couldn't repro, however, you added the DCHECK just recently, so maybe you know what's going on?
,
Apr 18 2017
Looks like the same as issue 704530 . What happens is that we read a markbit and figure out it is grey. We should always be able to read the next markbit in this case, which is the invariant the DCHECK is checking.
,
Apr 18 2017
So the DCHECK isn't hit as a side effect of Chromium leaking live objects on this page? On device we run out of memory before hitting this DCHECK so the high memory usage (more than 512M) is our main concern.
,
Apr 18 2017
Unfortunately no, the DCHECK is part of an invariant check and unrelated to high memory usage or leaks in general. High memory usage potentially stresses the GC, flushing out these sorts of bugs though.
,
Apr 19 2017
Will you investigate the high memory usage in issue 704530 or shall that be handled as a separate issue?
,
Apr 19 2017
Please open up another issue stating that the high memory usage is the problem so that the current sheriffs can pick it up as I won't have time to dig into this right now.
,
Apr 19 2017
Thanks, I opened issue 713043 for the memory issue. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by hablich@chromium.org
, Apr 12 2017Status: Available (was: Untriaged)