Unfortunately I think the chrome debug logs are not enough information for us to debug this crash (e.g. they mostly contain console log messages and histograms).

Can you provide a smaller repo that we can run to experience the crash?

Thanks for reporting the issue.

@ sarvesh.n-- Could you please provide us the crash id and respond to the comment #2.'

Please add me as a friend on Facebook https://www.facebook.com/sarvesh.spn, will grant the relevant Facebook id the access to the FB app so you can repro it

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@ sarvesh.n : Thanks for the update!  if possible,Please create new profile without extensions and apps.Re-check once and let us know the observations and  provide recent crash from chrome://crashes/ of the issue which would help us to triage the issue further.

Thanks in Advance.

Here's one report 

Uploaded Crash Report ID b179473b87b231a4 (Local Crash ID: d307bd99-6fc1-4690-83a8-d6df83426723)

Crash report captured on Monday, September 4, 2017 at 6:24:36 PM, uploaded on Monday, September 4, 2017 at 6:24:47 PM

Apart from the Crash ID above, all the above debug logs I had attached prior have the same sequence of code before the crash - can we use this info to debug further?

68:4084:0831/182909.575:INFO:CONSOLE(28)] "OverrideNativeMethod cafe2.rad::BaseUI/removeAllChildren", source: https://fb-feature15-usw2-farm2-dev-7.farm2.zynga.com/scaleform/zynga.swfobject.js (28)
[6268:4084:0831/182909.575:INFO:CONSOLE(28)] "OverrideNativeMethod cafe2.rad::BaseUI/removeAllChildren", source: https://fb-feature15-usw2-farm2-dev-7.farm2.zynga.com/scaleform/zynga.swfobject.js (28)
[6268:4084:0831/182909.575:INFO:CONSOLE(28)] "OverrideNativeMethod cafe2.rad::BaseUI/removeAllChildren", source: https://fb-feature15-usw2-farm2-dev-7.farm2.zynga.com/scaleform/zynga.swfobject.js (28)
[6268:4084:0831/182909.575:INFO:CONSOLE(28)] "OverrideNativeMethod cafe2.rad::BaseUI/removeAllChildren", source: https://fb-feature15-usw2-farm2-dev-7.farm2.zynga.com/scaleform/zynga.swfobject.js (28)
[6268:4084:0831/182909.632:INFO:CONSOLE(34)] "frame[184] time:0.76s memory:948.21MB", source: https://fb-feature15-usw2-farm2-dev-7.farm2.zynga.com/scaleform/zynga.swfobject.js (34)
[6268:4084:0831/182909.656:INFO:CONSOLE(28)] "UsingNativeClassDefinition: Engine.Utilities::Json", source: https://fb-feature15-usw2-farm2-dev-7.farm2.zynga.com/scaleform/zynga.swfobject.js (28)
[6268:4084:0831/182909.656:INFO:CONSOLE(28)] "UsingNativeClassDefinition: by.blooddy.crypto.serialization::JSON", source: https://fb-feature15-usw2-farm2-dev-7.farm2.zynga.com/scaleform/zynga.swfobject.js (28)
[6268:4084:0831/182909.675:INFO:CONSOLE(1170)] "Uncaught RangeError: Maximum call stack size exceeded", source: wasm://wasm/03a897da (1170)

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

> tps://fb-feature15-usw2-farm2-dev-7.farm2.zynga.com/scaleform/zynga.swfobject.js (28)
[6268:4084:0831/182909.675:INFO:CONSOLE(1170)] "Uncaught RangeError: Maximum call stack size exceeded", source: wasm://wasm/03a897da (1170)

I didn't see that before (probably because I didn't go through the entire log that closely).

How deep are your call stacks? This error is generated when function calls go too deep and run out of stack space.

It happens only on Chrome Windows (not Chrome Mac) and not on Firefox

Would there be anyway to inspect the call stack at the time of crash, To see which of the code causes it? Also do you think the above wasm error is the cause of the crash? Any reason why it would not happen on Firefox with same build/and why it would not happen on Mac with Chrome build and only on windows?

BTW the error consistently happening on Chrome Canary and Chrome 61 as well

Here's another Report

Uploaded Crash Report ID 78805501c2025870 (Local Crash ID: 71006ccd-8ff6-4a7b-ae39-ba81bbf3f9ff)

Crash report captured on Thursday, September 7, 2017 at 3:08:54 PM, uploaded on Thursday, September 7, 2017 at 3:08:56 PM

Another Recent Crash Report with the Debug Logs

Uploaded Crash Report ID 44e3f6d9ccc8e3db (Local Crash ID: 7d214396-bb01-4bbf-95f5-185761cb8ddb)

Crash report captured on Thursday, September 7, 2017 at 3:54:49 PM, uploaded on Thursday, September 7, 2017 at 3:54:51 PM

Deleted: chrome_debug.log 5.8 MB

chrome_debug.log 5.8 MB View Download

Thanks for the update! Checked with provided crash id's in crash server.Updating the below details as per crash server.

Stack Trace:
------------
Thread 0 (id: 12712) MAGIC SIGNATURE THREAD
Stack Quality92%Show frame trust levels
0x00007ffdf4fcab7c	(libglesv2.dll -framebufferd3d.cpp:315 )	rx::FramebufferD3D::syncState(gl::Context const *,angle::BitSetT<18,unsigned __int64> const &)
0x00003fff		
0x00007ffdf4ee4889	(libglesv2.dll -framebuffer.cpp:1496 )	gl::Framebuffer::syncState(gl::Context const *)
0x00007ffdf4ee3d24	(libglesv2.dll -framebuffer.cpp:1040 )	gl::Framebuffer::checkStatusImpl(gl::Context const *)
0x00007ffdf4ee3930	(libglesv2.dll -framebuffer.cpp:848 )	gl::Framebuffer::checkStatus(gl::Context const *)
0x00007ffdf4e8da74	(libglesv2.dll -validationes2.cpp:2502 )	gl::ValidateClear(gl::ValidationContext *,unsigned int)
0x00007ffdf4e52a45	(libglesv2.dll -entry_points_gles_2_0_autogen.cpp:284 )	gl::Clear(unsigned int)
0x00007ffde5d49bf8	(chrome_child.dll -gl_gl_api_implementation.cc:414 )	gl::RealGLApi::glClearFn(unsigned int)
0x00007ffde67ab3bb	(chrome_child.dll -gles2_cmd_decoder.cc:7512 )	gpu::gles2::GLES2DecoderImpl::DoClear(unsigned int)
0x00007ffde67bbb97	(chrome_child.dll -gles2_cmd_decoder_autogen.h:356 )	gpu::gles2::GLES2DecoderImpl::HandleClear(unsigned int,void const volatile *)
0x00007ffde67a0dc1	(chrome_child.dll -gles2_cmd_decoder.cc:5381 )	gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<0>(unsigned int,void const volatile *,int,int *)
0x00007ffde67ab80e	(chrome_child.dll -gles2_cmd_decoder.cc:5432 )	gpu::gles2::GLES2DecoderImpl::DoCommands(unsigned int,void const volatile *,int,int *)
0x00007ffde679e0cd	(chrome_child.dll -command_buffer_service.cc:90 )	gpu::CommandBufferService::Flush(int,gpu::AsyncAPIInterface *)
0x00007ffde68ba546	(chrome_child.dll -gpu_command_buffer_stub.cc:996 )	gpu::GpuCommandBufferStub::OnAsyncFlush(int,unsigned int,std::vector<ui::LatencyInfo,std::allocator<ui::LatencyInfo> > const &)
0x00007ffde68b801c	(chrome_child.dll -ipc_message_templates.h:146 )	IPC::MessageT<GpuCommandBufferMsg_AsyncFlush_Meta,std::tuple<int,unsigned int,std::vector<ui::LatencyInfo,std::allocator<ui::LatencyInfo> > >,void>::Dispatch<gpu::GpuCommandBufferStub,gpu::GpuCommandBufferStub,void,void ( gpu::GpuCommandBufferStub::*)(int,unsigned int,std::vector<ui::LatencyInfo,std::allocator<ui::LatencyInfo> > const &)>(IPC::Message const *,gpu::GpuCommandBufferStub *,gpu::GpuCommandBufferStub *,void *,void ( gpu::GpuCommandBufferStub::*)(int,unsigned int,std::vector<ui::LatencyInfo,std::allocator<ui::LatencyInfo> > const &))
0x00007ffde68baeb1	(chrome_child.dll -gpu_command_buffer_stub.cc:308 )	gpu::GpuCommandBufferStub::OnMessageReceived(IPC::Message const &)
0x00007ffde68b3c4d	(chrome_child.dll -gpu_channel.cc:1037 )	gpu::GpuChannel::HandleMessageHelper(IPC::Message const &)
0x00007ffde68b3b96	(chrome_child.dll -gpu_channel.cc:985 )	gpu::GpuChannel::HandleMessage(IPC::Message const &)
0x00007ffde5ff7e35	(chrome_child.dll -bind_internal.h:318 )	base::internal::Invoker<base::internal::BindState<void ( content::ResourceSchedulingFilter::*)(IPC::Message const &),base::WeakPtr<content::ResourceSchedulingFilter>,IPC::Message>,void >::RunOnce(base::internal::BindStateBase *)
0x00007ffde4a78409	(chrome_child.dll -callback.h:64 )	base::OnceCallback<void >::Run( ?? )
0x00007ffde67e5033	(chrome_child.dll -scheduler.cc:502 )	gpu::Scheduler::RunNextTask()
0x00007ffde48adcd7	(chrome_child.dll -bind_internal.h:331 )	base::internal::Invoker<base::internal::BindState<void ( blink::TimerBase::*)(void),base::WeakPtr<blink::TimerBase> >,void >::Run(base::internal::BindStateBase *)
0x00007ffde48e9b7e	(chrome_child.dll -task_annotator.cc:65 )	base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask *)
0x00007ffde48ece37	(chrome_child.dll -message_loop.cc:406 )	base::MessageLoop::RunTask(base::PendingTask *)
0x00007ffde48ea3ab	(chrome_child.dll -message_loop.cc:524 )	base::MessageLoop::DoWork()
0x00007ffde48e845a	(chrome_child.dll -message_pump_default.cc:33 )	base::MessagePumpDefault::Run(base::MessagePump::Delegate *)
0x00007ffde4a3cb93	(chrome_child.dll -run_loop.cc:123 )	base::RunLoop::Run()
0x00007ffde4c445cd	(chrome_child.dll -gpu_main.cc:302 )	content::GpuMain(content::MainFunctionParams const &)
0x00007ffde48ca239	(chrome_child.dll -content_main_runner.cc:426 )	content::RunNamedProcessTypeMain(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,content::MainFunctionParams const &,content::ContentMainDelegate *)
0x00007ffde48ca028	(chrome_child.dll -content_main_runner.cc:709 )	content::ContentMainRunnerImpl::Run()
0x00007ffde4c44d3f	(chrome_child.dll -main.cc:469 )	service_manager::Main(service_manager::MainParams const &)
0x00007ffde4c44b42	(chrome_child.dll -content_main.cc:19 )	content::ContentMain(content::ContentMainParams const &)
0x00007ffde4c44aea	(chrome_child.dll -chrome_main.cc:122 )	ChromeMain
0x00007ff746f8761e	(chrome.exe -main_dll_loader_win.cc:199 )	MainDllLoader::Launch(HINSTANCE__ *,base::TimeTicks)
0x00007ff746f82620	(chrome.exe -chrome_exe_main_win.cc:275 )	wWinMain
0x00007ff74704f632	(chrome.exe -exe_common.inl:253 )	__scrt_common_main_seh
0x00007ffe1ebf2773	(KERNEL32.DLL + 0x00012773 )	BaseThreadInitThunk
0x00007ffe1f1c0d50	(ntdll.dll + 0x00070d50 )	

Thread 1 (id: 8308) CRASHED [EXCEPTION_ACCESS_VIOLATION_WRITE @ 0x00000000 ]
Stack Quality86%Show frame trust levels
0x00007ffde5d78c62	(chrome_child.dll -gpu_watchdog_thread.cc:421 )	gpu::GpuWatchdogThread::DeliberatelyTerminateToRecoverFromHang()
0x00007ffde5d78e0b	(chrome_child.dll -gpu_watchdog_thread.cc:291 )	gpu::GpuWatchdogThread::OnCheckTimeout()
0x00007ffde48d4e61	(chrome_child.dll -bind_internal.h:331 )	base::internal::Invoker<base::internal::BindState<void ( blink::HTMLDocumentParser::*)(void),base::WeakPtr<blink::HTMLDocumentParser> >,void >::Run(base::internal::BindStateBase *)
0x00007ffde48e9b7e	(chrome_child.dll -task_annotator.cc:65 )	base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask *)
0x00007ffde48ece37	(chrome_child.dll -message_loop.cc:406 )	base::MessageLoop::RunTask(base::PendingTask *)
0x00007ffde4c74b17	(chrome_child.dll -message_loop.cc:417 )	base::MessageLoop::DeferOrRunPendingTask(base::PendingTask)
0x00007ffde48e8aef	(chrome_child.dll -message_loop.cc:564 )	base::MessageLoop::DoDelayedWork(base::TimeTicks *)
0x00007ffde48e8478	(chrome_child.dll -message_pump_default.cc:37 )	base::MessagePumpDefault::Run(base::MessagePump::Delegate *)
0x00007ffde4a3cb93	(chrome_child.dll -run_loop.cc:123 )	base::RunLoop::Run()
0x00007ffde4a3caa2	(chrome_child.dll -thread.cc:338 )	base::Thread::ThreadMain()
0x00007ffde4a4af6f	(chrome_child.dll -platform_thread_win.cc:89 )	base::`anonymous namespace'::ThreadFunc
0x00007ffe1ebf2773	(KERNEL32.DLL + 0x00012773 )	BaseThreadInitThunk
0x00007ffe1f1c0d50	(ntdll.dll + 0x00070d50 )	
0x00007ffe1b8967bf	(KERNELBASE.dll + 0x000067bf )	

1)This crash is first started on 55.0.2883.87 and on latest Beta 61.0.3163.79 seeing 1 from 1 different clients.
2)This crash only seen on Windows>GPU-Process.
3)This crash is not seen in latest Canary(62.0.3208.0) & Dev(62.0.3202.9).

61.0.3163.79	0.01%	1	-Beta & Stable
61.0.3163.71	0.01%	1	
61.0.3163.59	0.04%	5	
61.0.3163.49	0.03%	4	
61.0.3163.39	0.05%	6	
61.0.3163.31	0.02%	2	
61.0.3163.26	0.01%	1	
60.0.3112.113	5.71%	664	-Prev.Stable

Link to the list of builds:
---------------------------
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27gpu-process%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BGPU%20hang%5D%20ANGLE%3A%20rx%3A%3AFramebufferD3D%3A%3AsyncState%27&sql_dialect=dremelsql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&unnest=#-property-selector,samplereports:5,+productversion:1000

Using source and code search for the file, "FramebufferD3D.cpp" suspecting the following CL.

https://chromium.googlesource.com/angle/angle.git/+/c564c070ff68a2f369ebb048d3c49847a2d342cf%5E%21/src/libANGLE/renderer/d3d/FramebufferD3D.cpp

@jmadill: Could you please look into the issue, kindly re-assign if this is not related to your changes.

Thank You!

We have enabled Chrome crash logging, however most of the times crash id is not generated even though we get Aw snap...can it be because we launch Chrome from command line, what would be the right way to ensure that crash id is always generated?

Here's the another instance of the crash.

Uploaded Crash Report ID 32d287b8127d77e7 (Local Crash ID: 52b2cfcd-5ae8-42b4-a7cf-c5e7ba28f94f)

Crash report captured on Thursday, September 7, 2017 at 4:05:35 PM, uploaded on Thursday, September 7, 2017 at 5:56:20 PM

Aw Snap crash...
Uploaded Crash Report ID 6de3d9d432bec925 (Local Crash ID: 25225ce1-805b-4a78-9aab-87682a2ee702)

Crash report captured on Friday, September 8, 2017 at 12:21:05 AM, uploaded on Friday, September 8, 2017 at 12:21:08 AM

Yes, given the stack trace, it looks like a WebGL issue.

Yes, Since the above issue never happens on Mac and always happens on Windows, it seems to definitely be a Windows and maybe Direct3D? issue, so the FrameBufferD3D stack might be the right thing to be fixed

The stack trace inside rx::FramebufferD3D::syncState came from crash ID b179473b87b231a4. It wasn't a crash in that function, but a GPU hang and termination via the GPU watchdog. Now, there have been some bugs in the watchdog being fixed in Issue 729686, but that should only affect laptops being suspended/resumed and I doubt that's the issue here.

Crashes of Chrome's GPU process would not cause "Aw, snap!" to be displayed unless something went wrong in the renderer process too, and that would be evident in the crash report.

Crash IDs:
78805501c2025870
44e3f6d9ccc8e3db
32d287b8127d77e7

all state in the crash report:
"This is a hang caused by slow script and not a Chrome bug per https://code.google.com/p/chromium/issues/detail?id=540627#c3"

Crash ID 6de3d9d432bec925 was an accidental visit to about:crash instead of about:crashes.

I'm moving this back into the WebAssembly component but keeping ANGLE folks and myself CC'd because I don't see hard evidence that this is caused by ANGLE or the WebGL implementation. Speaking with Zynga yesterday, it sounded like there might be a codegen bug in WebAssembly. More investigation and a repro case are needed.

We did some more testing today with pure asmjs export on Chrome 59, and noticed that the issue does not happen with asmjs export on Chrome 59, 60 and 61(and wasm conversion disabled)...
1.)This may point it is a WASM issue?  
2.)Also for slow scripts does WASM show a popup saying to allow or continue?  Would that cause a crash? (Do you have details of the function from the crash ids?)

Here's the another instance of the crash.

Uploaded Crash Report ID 2b26264e8ebe8d5c (Local Crash ID: 4b41d186-776d-44b0-8fb6-f81f995ff9f0)

Crash report captured on Tuesday, September 12, 2017 at 1:44:29 PM, uploaded on Tuesday, September 12, 2017 at 1:44:31 PM 

The indication from crash ID 2b26264e8ebe8d5c is that it's caused by the main thread hanging for too long.

Magic Signature[Renderer hang] v8::internal::`anonymous namespace'::Invoke
(crbug 751233, crbug 721344)
This is a hang caused by slow script and not a Chrome bug per https://code.google.com/p/chromium/issues/detail?id=540627#c3by dominicc@ -- 2 years ago
edit bugs&comments
User bug(s): crbug 708512, crbug 714667, crbug 721573, crbug 721605, crbug 721603, crbug 728302

Thread 0 (id: 9900) MAGIC SIGNATURE THREAD

	0x0000002166d6b5c6		
0x0000002166fbfcee		
0x0000002166f95ac1		
0x0000002166f42aeb		
0x0000002166f6a565		
0x0000002166bd2902		
0x0000002166bc6664		
0x0000002166bca49c		
0x0000002166bddb30		
0x0000002166ff2931		
0x0000002166f69d93		
0x00000021670f0fbe		
0x0000002166f9b75c		
0x0000002166f42aeb		
0x0000002166f6a565		
0x0000002166d404d1		
0x0000002166cfaadf		
0x0000002166c69d2e		
0x0000002166c70a0c		
0x0000002167251ad0		
0x00000021671a0ca5		
0x0000002166f9b3c8		
0x0000002166f42aeb		
0x0000002166f6a565		
0x0000002166d404d1		
0x0000002166cfabbf		
0x0000002166ce3913		
0x0000002166cd6968		
0x0000002166a9a170		
0x0000002166a7809e		
0x000000216640e8c3		
0x0000002166a5f0e9		
0x000000216641a148		
0x0000002166420de7		
0x000000216643beb1		
0x000000216544087a		
0x000000216543f206		
0x0000002165e14661		
0x00000021653718c9		
0x000000216729cee0		
0x0000002167799ff8		
0x0000002165185eda		
0x000000216523e459		
0x0000002165184160		
0x00007ffa00cf1710	(chrome_child.dll -execution.cc:145 )	v8::internal::`anonymous namespace'::Invoke
0x00007ffa00cf15f2	(chrome_child.dll -execution.cc:191 )	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)
0x00007ffa00cbcea5	(chrome_child.dll -api.cc:5324 )	v8::Function::Call(v8::Local<v8::Context>,v8::Local<v8::Value>,int,v8::Local<v8::Value> * const)
0x00007ffa00f3d196	(chrome_child.dll -v8scriptrunner.cpp:696 )	blink::V8ScriptRunner::CallFunction(v8::Local<v8::Function>,blink::ExecutionContext *,v8::Local<v8::Value>,int,v8::Local<v8::Value> * const,v8::Isolate *)
0x00007ffa00d03a01	(chrome_child.dll -v8framerequestcallback.cpp:51 )	blink::V8FrameRequestCallback::handleEvent(double)
0x00007ffa00d9ac65	(chrome_child.dll -framerequestcallbackcollection.cpp:77 )	blink::FrameRequestCallbackCollection::ExecuteCallbacks(double,double)
0x00007ffa00d9ab3d	(chrome_child.dll -scriptedanimationcontroller.cpp:136 )	blink::ScriptedAnimationController::ExecuteCallbacks(double)
0x00007ffa00d9aa20	(chrome_child.dll -scriptedanimationcontroller.cpp:165 )	blink::ScriptedAnimationController::ServiceScriptedAnimations(double)
0x00007ffa00e43dcf	(chrome_child.dll -pageanimator.cpp:75 )	blink::PageAnimator::ServiceScriptedAnimations(double)
0x00007ffa00d73e61	(chrome_child.dll -webviewimpl.cpp:1987 )	blink::WebViewImpl::BeginFrame(double)
0x00007ffa00fccf36	(chrome_child.dll -proxy_main.cc:185 )	cc::ProxyMain::BeginMainFrame(std::unique_ptr<cc::BeginMainFrameAndCommitState,std::default_delete<cc::BeginMainFrameAndCommitState> >)
0x00007ffa00fccc0b	(chrome_child.dll -bind_internal.h:316 )	base::internal::Invoker<base::internal::BindState<void ( cc::ProxyMain::*)(std::unique_ptr<cc::BeginMainFrameAndCommitState,std::default_delete<cc::BeginMainFrameAndCommitState> >),base::WeakPtr<cc::ProxyMain>,base::internal::PassedWrapper<std::unique_ptr<cc::BeginMainFrameAndCommitState,std::default_delete<cc::BeginMainFrameAndCommitState> > > >,void >::RunOnce(base::internal::BindStateBase *)
0x00007ffa00d41b12	(chrome_child.dll -task_annotator.cc:59 )	base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask *)
...

And in another thread:

Thread 20 (id: 11616) CRASHED [Simulated Exception @ 0x00007ffa1935a57b ]
Stack Quality75%Show frame trust levels
0x00007ffa1935a57b	(chrome_elf.dll -crashpad.cc:304 )	crash_reporter::DumpWithoutCrashing()
0x00007ffa1935c7ba	(chrome_elf.dll -crashpad_win.cc:174 )	crash_reporter::internal::`anonymous namespace'::DumpProcessForHungInputThread
0x00007ffa42ee2773	(KERNEL32.DLL + 0x00012773 )	BaseThreadInitThunk
0x00007ffa43000d50	(ntdll.dll + 0x00070d50 )	

I'm not sure whether the "slow script" dialog pops up for WebAssembly content.

Brad, can you own this and find someone to investigate?

Attaching a windbg dump file generated at time of crash by attaching windbg since a lot of the Aw snaps dont give a crash id.

Deleted: 20170913dump3.dmp 25.5 KB

20170913dump3.dmp 25.5 KB Download

The Aw Snap issue happens all of a sudden during the game play. Check the video: https://drive.google.com/file/d/0B4pS3dbDonCwdmtubko1MUZIN3M/view from time 14:15s onwards.

Unfortunately this Aw Snap does not generate any CrashIds. The chrome://crashes is not updated with the crash.
This happens consistently on Windows only, on Chrome after 5-10mins of game play.

Please add a friend request on Facebook https://www.facebook.com/sarvesh.spn, and we can grant the relevant Facebook id the access to the FB app so you can repro it.

We observed that the Aw snap issue stops once we preallocate 2GB memory for WASM, (though all the above individual cases of Aw snap happen at a memory much less than 2GB , i.e. 1.6GB or so) . This could indicate that the default MEMORY GROWTH for wasm might not be able to keep up to pace with which the application allocates memory, is there any way to tune it for larger chunks of allocation on every subsequent memory growth to avoid 2GB in advance?   (Firefox works fine though with no preallocated allocation)

I did some more exploration of this today and I think some facts that help clarify the issue came out. No silver bullet but I think some good info.

1. I edited the emscripten src/preamble.js to improve emscripten's logging for WASM heap resizes. The .js method is here: (note this is tag 1.37.21 their latest release):  https://github.com/kripken/emscripten/blob/1.37.21/src/preamble.js#L2413
I can certainly say that we fail when resizing the heap (while making the Module['wasmMemory'].grow() call).

2. When building with emscripten ASSERTS flag (-s ASSERTS=1) some additional heap resize timing info is dumped, and I'm seeing heap resizing take quite a long time, even on my relatively recent development machine, furthermore the time required grows as the heap grows. Some of the relevant log info:
enlarged memory arrays from 1807745024 to 1892679680, took 1709 ms (has ArrayBuffer.transfer? false)
It's clear to me we're failing during this (growing) time period where the heap is being resized.
For reference, on firefox the relevant heap resizing time is much smaller and nearly constant:
enlarged memory arrays from 1807745024 to 1892679680, took 2 ms (has ArrayBuffer.transfer? false)

3. Lastly, I did some small C++ test of growing the heap in hopes of recreating this failure independently, but was not able to. I was able to cleanly grow the heap without failure in separate tests. The timing info did resemble the above log, however (resizing time can grow to 1 or 2 full seconds at large heap resizes). But my test was very simple. I imagine we're doing something during this heap growth period that is causing the failure, but as yet I'm not able to isolate further.

Adding Bill, who is working in this area.

Given the complexity of this problem space and the diversity of user configurations (i.e., there are still a lot of users w/ 2 GB of RAM or less), I'd strongly recommend looking for ways to optimize for resource utilization.

+Bill for real this time.

The bug is marked M61. We pre-reserve memory on 32 bit Windows systems starting with M62. One consequence of the reservation is that OOM's may happen sooner when the renderer process is committing more than 1.5 GB of memory. Are you observing this problem on Dev channel Chrome (M62)?

I'm actually experiencing this bug on Canary 63.0.3218.0 64bit on a 64bit windows system (windows 7 Enterprise). Perhaps this bug has been miscategorized?

Then it sounds like it's not due to address space exhaustion.

This issue continues to occur on latest Chrome/Chrome Canary as well...We preallocate memory to 2GB to fix this as of now, however the blobs we are testing are only 1.4 or 1.5 GB of memory....so it looks like Chrome is maybe not able to catch up with the rapid memory growth in the application and causes the Aw snap? However we dont need any of the preallocation in Firefox...so looks like some issue with the Chrome wasm memory growth implementation