New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 775952 link

Starred by 5 users

Issue metadata

Status: Fixed
Merged: issue 502298
Owner:
Last visit > 30 days ago
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Repeated worker create/terminate crashes

Reported by raph.lev...@gmail.com, Oct 18 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36

Steps to reproduce the problem:
1. Open index.html of attached test case
2. Repro is more reliable with dev tools console open
3. Counter shows number of worker lifecycles; crash usually happens after a few hundred

What is the expected behavior?
It keeps going, and going, and going.

What went wrong?
Aw, snap. I did look at a couple of chrome_debug.logs but saw nothing consistent. One was:

```
[57924:31491:1018/001903.361857:VERBOSE1:shutdown_signal_handlers_posix.cc(147)] Handling shutdown for signal 2.
```
But I also saw `ERROR:browser_gpu_channel_host_factory.cc(103)] Failed to launch GPU process.` in the crossword editing app we're working on.

In addition, CPU usage is dramatically higher than the 100% expected, and the main HTML5 app is very janky (visible even with the simple counter, but extremely noticeable in the app).

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 62.0.3202.62  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

The test case is very simple, it just creates a memory-intensive WASM worker every 200ms, terminating the previous one.

I said "yes" for the "other browsers" question because it appears flawless in Firefox (both stability and performance). However, Safari is even worse.
 
worker_crash.tar.gz
50.6 KB Download

Comment 1 by falken@chromium.org, Oct 18 2017

This looks similar to issue 502298
Mergedinto: 502298
Status: Duplicate (was: Unconfirmed)

Comment 3 by falken@chromium.org, Oct 19 2017

raph.levien@: Do you get a crash ID in chrome://crashes after the Sad Tab occurs?
I created one just now (didn't have auto crash reporting enabled)

Uploaded Crash Report ID ecf5ad551a8a69a0 (Local Crash ID: 4e6947c0-4632-42b9-90eb-4ef9e86cdb37)

Comment 5 by falken@chromium.org, Oct 19 2017

Cc: kozyatinskiy@chromium.org
Components: Platform>DevTools>JavaScript
Status: Available (was: Duplicate)
kozyatinskiy: Could the crash be related to issue 752019? The stack trace is similar and the magic signature  "v8::internal::`anonymous namespace'::ConsoleCall" maps to that bug. However that bug says it was fixed in 6.0.3198.0 and this crash is from 62.0.3202.62.

0x0000000113308ad2	(Google Chrome Framework -platform-posix.cc:248 )	v8::base::OS::Abort()
0x000000010f9ad7ae	(Google Chrome Framework -builtins-console.cc:65 )	v8::internal::(anonymous namespace)::ConsoleCall(v8::internal::Isolate*, v8::internal::BuiltinArguments&, void (v8::debug::ConsoleDelegate::*)(v8::debug::ConsoleCallArguments const&, v8::debug::ConsoleContext const&))
0x000000010f9aa473	(Google Chrome Framework -builtins-console.cc:74 )	v8::internal::Builtin_ConsoleWarn(int, v8::internal::Object**, v8::internal::Isolate*)
0x000010be4138697c		
0x000010be4143d17f		
0x000010be4143d17f		
0x000010be414cd15d		
0x000010be414b853c		
0x000010be414bfd12		
0x000010be414c65c0		
0x000010be414cb94b		
0x000010be4138535e		
0x000010be4143d17f		
0x000010be4138535e		
0x000010be4143d17f		
0x000010be4143d17f		
0x000010be4143d17f		
0x000010be4138535e		
0x000010be4143d17f		
0x000010be4143d17f		
0x000010be4143d17f		
0x000010be4143d17f		
0x000010be41409cdb		
0x000010be41384238		
0x000010be41384100		
0x000000010fc020c2	(Google Chrome Framework -execution.cc:145 )	v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, bool, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, v8::internal::Handle<v8::internal::Object>, v8::internal::Execution::MessageHandling)
0x000000010fc022c4	(Google Chrome Framework -execution.cc:181 )	v8::internal::Execution::TryCall(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, v8::internal::Execution::MessageHandling, v8::internal::MaybeHandle<v8::internal::Object>*)
0x000000010fd10c21	(Google Chrome Framework -isolate.cc:3436 )	v8::internal::Isolate::PromiseReactionJob(v8::internal::Handle<v8::internal::PromiseReactionJobInfo>, v8::internal::MaybeHandle<v8::internal::Object>*, v8::internal::MaybeHandle<v8::internal::Object>*)
0x000000010fd116cf	(Google Chrome Framework -isolate.cc:3509 )	v8::internal::Isolate::RunMicrotasksInternal()
0x000000010fd105e9	(Google Chrome Framework -isolate.cc:3489 )	v8::internal::Isolate::RunMicrotasks()
0x0000000113eaafbb	(Google Chrome Framework -WorkerThread.cpp:193 )	blink::WorkerThread::DidProcessTask()

Comment 6 by kozy@chromium.org, Oct 19 2017

Original fix dde44dd0... initially landed in 62.0.3199.0. So this crash looks suspicious. Maybe worker terminate send terminate exception to V8 and it happens inside of console call.
Owner: kozyatinskiy@chromium.org
Status: Assigned (was: Available)

Comment 8 by kozy@chromium.org, Dec 11 2017

Status: Fixed (was: Assigned)
There is no new crashes after M62 and it is too late to merge CL to M62.

Sign in to add a comment