Chromium V8 crash during PipelineImpl::OptimizeGraph
Reported by
rong1...@gmail.com,
Dec 2 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce the problem: We compiled the current Linux dev version (6.4.370.0) on a ARM-64 platform running Debian. The tab crashed when running a large web application during webrtc sessions. The same issue also happens with older Chromium versions, such as 61 and 63. We are trying to narrow it down to the offending piece of code so we can report it appropriately. Any advice on how to narrow down/troubleshoot the issue would be appreciated. 1. Compile the current Linux dev version (6.4.370.0) using the ARM-64 arch. 2. Run Chromium in headless mode ./chrome --no-sandbox --headless --use-fake-ui-for-media-stream --disable-gpu https://192.168.0.1 3. Observe the Stack trace in the terminal What is the expected behavior? The browser tab shouldn't crash. If there's problem with the JavaScript code, error or exception should be thrown to the JS application. What went wrong? After the WebRTC session being running for few minutes, we received this stack trace in the terminal: Received signal 11 SEGV_MAPERR 00007f2c0e79 #0 0x007f9ed5efb0 base::debug::StackTrace::StackTrace() #1 0x007f9ed5d6a8 base::debug::StackTrace::StackTrace() #2 0x007f9ed5edc8 base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x007f9f5094e0 ([vdso]+0x4df) #4 0x007f8e218620 v8::internal::compiler::VariableTracker::State::Get() #5 0x007f8e217b18 v8::internal::compiler::VariableTracker::MergeInputs() #6 0x007f8e2172b4 v8::internal::compiler::VariableTracker::Scope::Scope() #7 0x007f8e218b48 v8::internal::compiler::EscapeAnalysis::Reduce() #8 0x007f8e216cec v8::internal::compiler::EffectGraphReducer::ReduceFrom() #9 0x007f8e304110 v8::internal::compiler::EscapeAnalysisPhase::Run() #10 0x007f8e2fa218 v8::internal::compiler::PipelineImpl::OptimizeGraph() #11 0x007f8e2f9fbc v8::internal::compiler::PipelineCompilationJob::ExecuteJobImpl() #12 0x007f8e1a03d4 v8::internal::CompilationJob::ExecuteJob() #13 0x007f8e19c09c v8::internal::OptimizingCompileDispatcher::CompileNext() #14 0x007f8e19ceb8 v8::internal::OptimizingCompileDispatcher::CompileTask::RunInternal() #15 0x007f8ed48328 _ZN4base8internal13FunctorTraitsIMN2v84TaskEFvvEvE6InvokeINSt3__110unique_ptrIS3_NS8_14default_deleteIS3_EEEEJEEEvS5_OT_DpOT0_ #16 0x007f8ed4825c _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIMN2v84TaskEFvvEJNSt3__110unique_ptrIS5_NS8_14default_deleteIS5_EEEEEEEvOT_DpOT0_ #17 0x007f8ed481f8 _ZN4base8internal7InvokerINS0_9BindStateIMN2v84TaskEFvvEJNSt3__110unique_ptrIS4_NS7_14default_deleteIS4_EEEEEEEFvvEE7RunImplIS6_NS7_5tupleIJSB_EEEJLm0EEEEvOT_OT0_NS7_1 #18 0x007f8ed4810c _ZN4base8internal7InvokerINS0_9BindStateIMN2v84TaskEFvvEJNSt3__110unique_ptrIS4_NS7_14default_deleteIS4_EEEEEEEFvvEE7RunOnceEPNS0_13BindStateBaseE #19 0x007f9ed14dc0 _ZNO4base12OnceCallbackIFvvEE3RunEv #20 0x007f9ed646bc base::debug::TaskAnnotator::RunTask() #21 0x007f9ef57b18 base::internal::TaskTracker::RunOrSkipTask() #22 0x007f9ef5b3c8 base::internal::TaskTrackerPosix::RunOrSkipTask() #23 0x007f9ef55ca0 base::internal::TaskTracker::RunNextTask() #24 0x007f9ef41ed0 base::internal::SchedulerWorker::Thread::ThreadMain() #25 0x007f9ef66e8c base::(anonymous namespace)::ThreadFunc() #26 0x007f9f4ac0a0 start_thread [end of stack trace] Calling _exit(1). Core file will not be generated. Did this work before? No Chrome version: 64.0.3278.0 Channel: dev OS Version: Stretch Flash Version: Not installed
,
Dec 4 2017
Seems issue related to Headless hence adding OS 'Internals>Headless' component so that it would get addressed by respective team. Thanks..!!
,
Dec 4 2017
The page you are loading is internal to your network. In order to reproduce it, we would need a page that causes the crash. Ideally you would isolate as much of the web app as possible, then pare down the page itself until it no longer crashes. The last thing removed would then be suspect. Unfortunately, all this is telling us is that a page causes a crash. That isn't enough to debug with.
,
Dec 12 2017
We were able to narrow down the function that causing the crash, which is the function parse() in the attached file. It crashes when v8 trying to optimize parse() after running for a while. I was using the following command line to learn what V8 was doing at the time of crash. --js-flags="--trace-opt --trace-deopt --trace_codegen --use_verbose_printer --trace_opt_verbose --trace_file_names" The problem is I couldn't reliably reproduce the crash when I extracted the module out of our application stack and used it in a simplified test case. I tried adding option "--always_opt", but v8 never optimized parse() for whatever reason, although it did optimize other functions inside it, e.g. peg$parseRule(). Any idea how to force parse() to be optimized so I can reproduce the problem?
,
Dec 12 2017
Moving over to V8 as this doesn't seem headless specific.
,
Dec 14 2017
,
Jan 5 2018
Assigning to jarin for further triage.
,
Jan 5 2018
This looks like an escape analysis crash. Tobias, could you have a look?
,
Jan 8 2018
Compilation of the parse function can be forced by executing %OptimizeFunctionOnNextCall(parse) after some warm-up of the parse function that exercises enough code paths so we have collected feedback (this requires the additional flag --allow-natives-syntax). However, I don't have any sample input to feed into this parser, so even though I managed to trigger compilation of the parse function, I didn't manage to reproduce the crash. A valid test input that contains many constructs of the grammar might be helpful.
,
Jan 8 2018
,
Jan 21
(2 days ago)
We could not reproduce this. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by dtapu...@chromium.org
, Dec 3 2017