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

Issue 692233 link

Starred by 1 user
Status: Untriaged
Owner: ----
Cc:
█ ajwong@chromium.org
primiano@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

chrome://tracing under Linux reports V8Isolate MemoryDumpProvider threading issue

Project Member Reported by w...@chromium.org, Feb 14 2017 
Chrome Version: 58.0.3012.0 (64-bit) (local build)
OS: Linux

What steps will reproduce the problem?
(1) Run chrome with --enable-heap-profiling (and I had --enable-logging).
(2) Open chrome://tracing and start Recording.

What is the expected result?

Expect the console log to be blissfully silent.

What happens instead?

Lots of console log output of the form:

[1:9:0214/134130.630836:ERROR:memory_dump_manager.cc(597)] Disabling MemoryDumpProvider "V8Isolate". Failed to post task on the task runner provided.

Comment 1 by primiano@chromium.org, Feb 15 2017

Summary: chrome://tracing under Linux reports V8Isolate MemoryDumpProvider threading issue (was: chrome://tracing with --enable-heap-profiling under Linux reports V8Isolate MemoryDumpProvider threading issue)
That sounds like a thread for the v8 isolate disappeared (very likely a worker)  but the memory dump provider wasn't unregistered. Essentially it means that we tried to PostTask a dump request on whatever task runner passed by the v8 dump provider code and the PostTask returned false (read : the underlying message loop is gone)  
Does it repro systematically? If so might be a bug in the v8 memory dump provider (which lives in  gin/) 
Note : --enable-heap-profiling is irrelevant here, this has to do with the general memory-infra machinery.

Comment 2 by w...@chromium.org, Feb 17 2017 

No, I can't seem to repro it again right now.
►

Sign in to add a comment