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

Issue 600570 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Xoogler
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

Renderer crash when the heap profiler is enabled

Project Member Reported by bashi@chromium.org, Apr 4 2016

Issue description

What steps will reproduce the problem?
(1) chrome --enable-heap-profiling
(2) open chrome://tracing and start recoding with 'blink', 'v8', 'disabled-by-default-memory-infra' and 'disabled-by-default-v8' categories
(3) open a new tab and load http://edition.cnn.com

What is the expected output?
Recording successfully finished.

What do you see instead?
Renderer crash.

Please use labels and text to provide additional information.

It seems that process_memory_dump_->session_state() can be nullptr. Sample stacktrace:

Received signal 11 SEGV_MAPERR 000000000008
#0 0x7fbf822f265b base::debug::(anonymous namespace)::StackDumpSignalHandler()
#1 0x7fbf7a175340 <unknown>
#2 0x7fbf7fd26aee blink::WebProcessMemoryDumpImpl::dumpHeapUsage()
#3 0x7fbf7fc001aa blink::PartitionAllocMemoryDumpProvider::onMemoryDump()
#4 0x7fbf7fd2618f blink::WebMemoryDumpProviderAdapter::OnMemoryDump()
#5 0x7fbf82348d9d base::trace_event::MemoryDumpManager::InvokeOnMemoryDump()
#6 0x7fbf823484e5 base::trace_event::MemoryDumpManager::SetupNextMemoryDump()
#7 0x7fbf82348dfc base::trace_event::MemoryDumpManager::InvokeOnMemoryDump()
#8 0x7fbf823484e5 base::trace_event::MemoryDumpManager::SetupNextMemoryDump()
#9 0x7fbf82348dfc base::trace_event::MemoryDumpManager::InvokeOnMemoryDump()
#10 0x7fbf823484e5 base::trace_event::MemoryDumpManager::SetupNextMemoryDump()
#11 0x7fbf82348dfc base::trace_event::MemoryDumpManager::InvokeOnMemoryDump()
#12 0x7fbf823484e5 base::trace_event::MemoryDumpManager::SetupNextMemoryDump()
#13 0x7fbf82348dfc base::trace_event::MemoryDumpManager::InvokeOnMemoryDump()
#14 0x7fbf823484e5 base::trace_event::MemoryDumpManager::SetupNextMemoryDump()
#15 0x7fbf82348dfc base::trace_event::MemoryDumpManager::InvokeOnMemoryDump()
#16 0x7fbf823484e5 base::trace_event::MemoryDumpManager::SetupNextMemoryDump()
#17 0x7fbf82348dfc base::trace_event::MemoryDumpManager::InvokeOnMemoryDump()
#18 0x7fbf822f374c base::debug::TaskAnnotator::RunTask()

 
Cc: kraynov@chromium.org bashi@chromium.org
Labels: -Pri-3 Hotlist-MemoryInfra Pri-1
Owner: kraynov@chromium.org
Status: Assigned (was: Started)
+kraynov mind taking a look to this?
process_memory_dump_->session_state() should never be null, this smells like some kind of race. Can you plz figure out what's going on?
Project Member

Comment 2 by bugdroid1@chromium.org, Apr 14 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/063a22a7ad94d98b2d29bf3745dedea10313889f

commit 063a22a7ad94d98b2d29bf3745dedea10313889f
Author: kraynov <kraynov@chromium.org>
Date: Thu Apr 14 11:17:19 2016

Fix race condition when dump providers invoked within destroyed state

InvokeOnMemoryDump() should never be called when tracing is disabled
because dump providers can get unexpected destroyed session state.
This case also fortified with test case.

BUG= 600570 

Review URL: https://codereview.chromium.org/1884573002

Cr-Commit-Position: refs/heads/master@{#387281}

[modify] https://crrev.com/063a22a7ad94d98b2d29bf3745dedea10313889f/base/trace_event/memory_dump_manager.cc
[modify] https://crrev.com/063a22a7ad94d98b2d29bf3745dedea10313889f/base/trace_event/memory_dump_manager_unittest.cc

Status: Fixed (was: Assigned)
Components: Internals>Instrumentation>Memory

Sign in to add a comment