Loading JavaScript file > 256 MB fails CHECK |
|||||
Issue descriptionNoticed CHECK in tip-of-tree, commit ca125c61ee353. If a HTML page (see attached) is loaded that references a JavaScript file > 256 MB then the browser dies due to a failed CHECK. We should (hopefully) be able to do a runtime check earlier to avoid crashing the browser. Please email rjfioravanti@ for the large JS file (gmail-js.wHGTd,fiGdcb.js). [1:7:1127/111253.578363:FATAL:node_channel.cc(895)] Check failed: message->data_num_bytes() < GetConfiguration().max_message_num_bytes. #0 0x7fd0f38e23cc base::debug::StackTrace::StackTrace() #1 0x7fd0f3901b1c logging::LogMessage::~LogMessage() #2 0x7fd0efcc95c1 mojo::edk::NodeChannel::WriteChannelMessage() #3 0x7fd0efcc9f8d mojo::edk::NodeChannel::SendChannelMessage() #4 0x7fd0efccdfb9 mojo::edk::NodeController::SendPeerEvent() #5 0x7fd0efcce537 mojo::edk::NodeController::ForwardEvent() #6 0x7fd0efce2a1a mojo::edk::ports::Node::SendUserMessageInternal() #7 0x7fd0efce2890 mojo::edk::ports::Node::SendUserMessage() #8 0x7fd0efcccd81 mojo::edk::NodeController::SendUserMessage() #9 0x7fd0efcc89de mojo::edk::MessagePipeDispatcher::WriteMessage() #10 0x7fd0efcc0e8f mojo::edk::Core::WriteMessage() #11 0x7fd0f2d35687 mojo::Connector::Accept() #12 0x7fd0f2c86c9f IPC::(anonymous namespace)::ChannelAssociatedGroupController::SendMessage() #13 0x7fd0f2c86cce IPC::(anonymous namespace)::ChannelAssociatedGroupController::SendMessageOnMasterThread() #14 0x7fd0f2c86f09 _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12_GLOBAL__N_132ChannelAssociatedGroupControllerEFvN4mojo7MessageEEJ13scoped_refptrIS5_ENS0_13PassedWrapperIS7_EEEEEFvvEE3RunEPNS0_13BindStateBaseE #15 0x7fd0f38e2c7f base::debug::TaskAnnotator::RunTask() #16 0x7fd0f390a167 base::MessageLoop::RunTask() #17 0x7fd0f390a738 base::MessageLoop::DoWork() #18 0x7fd0f390c139 base::MessagePumpLibevent::Run() #19 0x7fd0f3931dc4 base::RunLoop::Run() #20 0x7fd0f3966c2d base::Thread::ThreadMain() #21 0x7fd0f396021d base::(anonymous namespace)::ThreadFunc() #22 0x7fd0f39e8494 start_thread #23 0x7fd0e8708a8f clone
,
Dec 5 2017
I got the script file. - I cannot reproduce the issue. - It is about 179MB, not 256MB.
,
Dec 5 2017
Yes, it's smaller: -rw-r--r-- 1 cmumford eng 187191910 Nov 27 10:47 gmail-js.wHGTd,fiGdcb.js Are you sure you did a reload?
,
Dec 5 2017
After trying more, I found the renderer sometimes crashed. cmumford@, you said "crashing the browser". Is the browser really crashed? We, chromium developers, distinguish renderer crash (Aw snap) and browser crash (entire application including many tabs will be gone).
,
Dec 5 2017
I suspect this is due to "CacheMetadata" IPC containing a too-big metadata, but I'm not familiar with CachedMetadata. hiroshige@ or horo@ may know more than me.
,
Dec 5 2017
There is a JavaScript source size limit in V8ScriptRunner::CompileScript(), but the limit is larger than 179MB (~256MB for 32-bit arch?). Reloading is required because V8 code caching creates metadata only when the script is loaded at least twice? https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/V8ScriptRunner.cpp?type=cs&q=V8ScriptRUnner::CompileScript&sq=package:chromium&l=397 Probably we have to set a limit in bindings/core/v8, or in CachedMetadataHandler. Not so sure about the threshold though. (The CHECK()'s limit is GetConfiguration().max_message_num_bytes (which is currently 256MB) but I'm not sure the size can be observed/checked/predicted from bindings/core/v8 or CachedMetadataHandler) +more people who are working on V8 code caching recently.
,
Dec 12 2017
Just so I understand the problem - is the crash when sending the code-cache metadata over IPC to the browser? If so, could we simply add a check after the code-cache has been produced and if it is too large, throw it away (we shouldn't be caching 256MB of cached code anyway...)?
,
Mar 14 2018
Loading triage: add a component for a v8 integration.
,
Mar 15 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by cmumford@chromium.org
, Nov 27 2017