the thread tried to read from or write to a virtual address for which it does not have access
Reported by
david.i....@gmail.com,
Jun 12 2016
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2766.0 Safari/537.36 Steps to reproduce the problem: 1. Create a js file with a lot of functions (thousands) that do a lot of object and array allocations locally 2. These functions should access to a big global json like data structure (add, edit delete nodes) 3. Execute these functions multiple times What is the expected behavior? Chrome is able to handle the load (before version 51 it was) What went wrong? chrome RAM usage goes through the roof (3 go and up). Aw Snap screen with the "the thread tried to read from or write to a virtual address for which it does not have access" error Did this work before? N/A Chrome version: 53.0.2766.0 Channel: canary OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 22.0 r0 I could package you a javascript/html package that you just click on a button and the problem will eventually occurs.
,
Jun 13 2016
Hello, here is the crash id 6ce8703c00000000
,
Jun 13 2016
Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 13 2016
Hi I will try to provide you with a sample soon. Thanks a lot for looking into this !
,
Jun 13 2016
,
Jun 14 2016
This is the sample I have. If you unzip it, in the folder "test" there is an "index.test.html" file. Open it and click on the "Inputs" button, above the first text area. Wait a couple of seconds for the processing to be completed. Redo this a couple of time and the crash should occurs. Thanks ! Please keep me informed if you are able to reproduce it or not.
,
Jun 14 2016
Its working in IE 11 .. but it is so much slower.
,
Jun 15 2016
,
Jun 15 2016
More information: We have a code converter that converts legacy code to javascript. Some of these legacy functions contain over 10000 lines of code (wow). It seems that it struggles with these huge function called multiple times in a row.
,
Jun 16 2016
Thanks for the test case provide. Able to reproduce the issue and is a non regression seen from M30 (30.0.1549.0) builds on Windows, MAC OS. Clicking the input button and waiting for some time crashes the page. Untriaging it so that it gets addressed. Removing bisect label Stack trace for the Crash ID generated: CRASHED [EXCEPTION_ACCESS_VIOLATION_WRITE @ 0x0000005305000000 ] MAGIC SIGNATURE THREAD 0x0000017d3f0df179 0x0000017d3e8150a0 0x0000017d3e247f34 0x0000017d3e240c41 0x0000017d3f0a7a9c 0x0000017d3e247f34 0x0000017d3e240c41 0x0000017d3e247f34 0x0000017d3e240c41 0x0000017d3e247f34 0x0000017d3e240c41 0x0000017d3e247f34 0x0000017d3e240c41 0x0000017d3e247f34 0x0000017d3e240c41 0x0000017d3e247f34 0x0000017d3e240c41 0x0000017d3e207814 0x0000017d3e247f34 0x0000017d3e240c41 0x0000017d3e247f34 0x0000017d3e240c41 0x0000017d3e2403a3 0x0000017d3e2284a2 0x000007fecc84884b (chrome_child.dll -execution.cc:98 ) v8::internal::`anonymous namespace'::Invoke 0x000007fecc848b54 (chrome_child.dll -execution.cc:154 ) v8::internal::Execution::Call(v8::internal::Isolate *,v8::internal::Handle<v8::internal::Object>,v8::internal::Handle<v8::internal::Object>,int,v8::internal::Handle<v8::internal::Object> * const) 0x000007fecadf4a38 (chrome_child.dll -api.cc:4453 ) v8::Function::Call(v8::Local<v8::Context>,v8::Local<v8::Value>,int,v8::Local<v8::Value> * const) 0x000007fecba5c1d5 (chrome_child.dll -v8scriptrunner.cpp:510 ) blink::V8ScriptRunner::callFunction(v8::Local<v8::Function>,blink::ExecutionContext *,v8::Local<v8::Value>,int,v8::Local<v8::Value> * const,v8::Isolate *) 0x000007fecbb09f8f (chrome_child.dll -v8lazyeventlistener.cpp:100 ) blink::V8LazyEventListener::callListenerFunction(blink::ScriptState *,v8::Local<v8::Value>,blink::Event *) 0x000007fecbab2e6a (chrome_child.dll -v8abstracteventlistener.cpp:130 ) blink::V8AbstractEventListener::invokeEventHandler(blink::ScriptState *,blink::Event *,v8::Local<v8::Value>) 0x000007fecbab2abf (chrome_child.dll -v8abstracteventlistener.cpp:95 ) blink::V8AbstractEventListener::handleEvent(blink::ScriptState *,blink::Event *) 0x000007fecbab2804 (chrome_child.dll -v8abstracteventlistener.cpp:84 ) blink::V8AbstractEventListener::handleEvent(blink::ExecutionContext *,blink::Event *) 0x000007fecb2aa4e3 (chrome_child.dll -eventtarget.cpp:593 ) blink::EventTarget::fireEventListeners(blink::Event *,blink::EventTargetData *,blink::HeapVector<blink::RegisteredEventListener,1> &) 0x000007fecb2a9eb3 (chrome_child.dll -eventtarget.cpp:498 ) blink::EventTarget::fireEventListeners(blink::Event *) 0x000007fecb245c2c (chrome_child.dll -node.cpp:2057 ) blink::Node::handleLocalEvents(blink::Event &) 0x000007feccd0d137 (chrome_child.dll -eventdispatcher.cpp:127 ) blink::EventDispatcher::dispatch() 0x000007fecb2bcaf1 (chrome_child.dll -mouseevent.cpp:291 ) blink::MouseEventDispatchMediator::dispatchEvent(blink::EventDispatcher &) 0x000007feccd0ca0f (chrome_child.dll -eventdispatcher.cpp:51 ) blink::EventDispatcher::dispatchEvent(blink::Node &,blink::EventDispatchMediator *) 0x000007fecb24fb83 (chrome_child.dll -eventhandler.cpp:1203 ) blink::EventHandler::handleMouseReleaseEvent(blink::PlatformMouseEvent const &) 0x000007fecaed32c7 (chrome_child.dll -pagewidgetdelegate.cpp:222 ) blink::PageWidgetEventHandler::handleMouseUp(blink::LocalFrame &,blink::WebMouseEvent const &) 0x000007fecaea80b8 (chrome_child.dll -webviewimpl.cpp:630 ) blink::WebViewImpl::handleMouseUp(blink::LocalFrame &,blink::WebMouseEvent const &) 0x000007fecaed30a0 (chrome_child.dll -pagewidgetdelegate.cpp:153 ) blink::PageWidgetDelegate::handleInputEvent(blink::PageWidgetEventHandler &,blink::WebInputEvent const &,blink::LocalFrame *) 0x000007fecaeac558 (chrome_child.dll -webviewimpl.cpp:2225 ) blink::WebViewImpl::handleInputEvent(blink::WebInputEvent const &) 0x000007fecbca21b0 (chrome_child.dll -render_widget_input_handler.cc:323 ) content::RenderWidgetInputHandler::HandleInputEvent(blink::WebInputEvent const &,ui::LatencyInfo const &,content::InputEventDispatchType) 0x000007fecbbf7f19 (chrome_child.dll -render_widget.cc:688 ) content::RenderWidget::OnHandleInputEvent(blink::WebInputEvent const *,ui::LatencyInfo const &,content::InputEventDispatchType) 0x000007fecbbfc085 (chrome_child.dll -ipc_message_templates.h:121 ) IPC::MessageT<InputMsg_HandleInputEvent_Meta,std::tuple<blink::WebInputEvent const *,ui::LatencyInfo,content::InputEventDispatchType>,void>::Dispatch<content::RenderWidget,content::RenderWidget,void,void ( content::RenderWidget::*)(blink::WebInputEvent const *,ui::LatencyInfo const &,content::InputEventDispatchType)>(IPC::Message const *,content::RenderWidget *,content::RenderWidget *,void *,void ( content::RenderWidget::*)(blink::WebInputEvent const *,ui::LatencyInfo const &,content::InputEventDispatchType)) 0x000007fecbbf6c8e (chrome_child.dll -render_widget.cc:483 ) content::RenderWidget::OnMessageReceived(IPC::Message const &) 0x000007fecbbb51c5 (chrome_child.dll -render_view_impl.cc:1322 ) content::RenderViewImpl::OnMessageReceived(IPC::Message const &) 0x000007fecc4f07e8 (chrome_child.dll -message_router.cc:52 ) IPC::MessageRouter::RouteMessage(IPC::Message const &) 0x000007fecbb5d5dc (chrome_child.dll -child_thread_impl.cc:666 ) content::ChildThreadImpl::OnMessageReceived(IPC::Message const &) 0x000007feca7dab93 (chrome_child.dll -bind_internal.h:364 ) base::internal::Invoker<base::IndexSequence<0>,base::internal::BindState<base::internal::RunnableAdapter<void ( extensions::CastStreamingNativeHandler::*)(v8::FunctionCallbackInfo<v8::Value> const &)>,void ,base::WeakPtr<extensions::CastStreamingNativeHandler> >,1,void >::Run(base::internal::BindStateBase *,v8::FunctionCallbackInfo<v8::Value> const &) 0x000007feca895cc3 (chrome_child.dll -task_annotator.cc:51 ) base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask const &) 0x000007feccfcc2b9 (chrome_child.dll -task_queue_manager.cc:289 ) scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(scheduler::internal::WorkQueue *,scheduler::internal::TaskQueueImpl::Task *) 0x000007feccfcba91 (chrome_child.dll -task_queue_manager.cc:201 ) scheduler::TaskQueueManager::DoWork(base::TimeTicks,bool) 0x000007feccfccdc5 (chrome_child.dll -bind_internal.h:364 ) base::internal::Invoker<base::IndexSequence<0,1,2>,base::internal::BindState<base::internal::RunnableAdapter<void ( scheduler::TaskQueueManager::*)(base::TimeTicks,bool)>,void ,base::WeakPtr<scheduler::TaskQueueManager>,base::TimeTicks,bool>,1,void >::Run(base::internal::BindStateBase *) 0x000007feca895cc3 (chrome_child.dll -task_annotator.cc:51 ) base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask const &) 0x000007feca85108e (chrome_child.dll -message_loop.cc:475 ) base::MessageLoop::RunTask(base::PendingTask const &) 0x000007feca852081 (chrome_child.dll -message_loop.cc:601 ) base::MessageLoop::DoWork() 0x000007feca89778f (chrome_child.dll -message_pump_default.cc:33 ) base::MessagePumpDefault::Run(base::MessagePump::Delegate *) 0x000007feca8974ec (chrome_child.dll -run_loop.cc:35 ) base::RunLoop::Run() 0x000007feca850520 (chrome_child.dll -message_loop.cc:294 ) base::MessageLoop::Run() 0x000007fecbbe9ea6 (chrome_child.dll -renderer_main.cc:199 ) content::RendererMain(content::MainFunctionParams const &) 0x000007feca817532 (chrome_child.dll -content_main_runner.cc:787 ) content::ContentMainRunnerImpl::Run() 0x000007feca769c88 (chrome_child.dll -chrome_main.cc:84 ) ChromeMain 0x000000013fed895e (chrome.exe -main_dll_loader_win.cc:185 ) MainDllLoader::Launch(HINSTANCE__ *) 0x000000013fed29d8 (chrome.exe -chrome_exe_main_win.cc:263 ) wWinMain 0x000000013ff65a95 (chrome.exe -exe_common.inl:255 ) __scrt_common_main_seh 0x76c059bc (kernel32.dll + 0x000159bc ) BaseThreadInitThunk 0x76d3a2e0 (ntdll.dll + 0x0002a2e0 ) RtlUserThreadStart
,
Jun 17 2016
,
Jun 20 2016
I reproduced this in GDB (recent Debug ToT build, first attempt) and am seeing a bit of zapped memory in the middle of new space, which crashes with a segfault during heap verification:
0x2a1af2fcce60: 0x0000014000000000
0x000021b3b2d15df1 // JSArray, size = 32 bytes
0x2a1af2fcce70: 0x000001c62c704249
0x00002690e0023d51
0x2a1af2fcce80: 0x0000000200000000
0x1beefdad0beefdaf // wat
0x2a1af2fcce90: 0x1beefdad0beefdaf
0x1beefdad0beefdaf
0x2a1af2fccea0: 0x1beefdad0beefdaf
0x1beefdad0beefdaf
0x2a1af2fcceb0: 0x1beefdad0beefdaf
0x1beefdad0beefdaf
0x2a1af2fccec0: 0x1beefdad0beefdaf
0x000021b3b2d16001 // JSArray, size = 32 bytes
0x2a1af2fcced0: 0x000001c62c704249
0x00002a1af2fccee9
0x2a1af2fccee0: 0x0000000200000000
0x0000324866404309
0x1beefdad0beefdaf is kFromSpaceZapValue, so I'd guess this is allocation folding going wrong and accidentally leaving a bit of unused space behind.
,
Jun 21 2016
Probably related to issue 621868 (clusterfuzz).
,
Jun 30 2016
It doesn't crash with Crankshaft allocation folding turned off. That sounds like a folding bug, indeed. I will have a look.
,
Jul 5 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 19 2017
This crasher was fixed. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ranjitkan@chromium.org
, Jun 13 2016Labels: Needs-Feedback