When we use --enable-heap-profiling in pseudo-stack mode, it may cause deadlock on MemoryDumpManager's lock.
Easily reproducible on Android.
This bot is red https://build.chromium.org/p/chromium.android.fyi/builders/Memory%20Infra%20Tester because of that.

The interesting and formated part os stack trace below:
base::AutoLock::ctor()                                                base/synchronization/lock.h:115
base::trace_event::MemoryDumpManager::RegisterDumpProviderInternal()  base/trace_event/memory_dump_manager.cc:402
base::trace_event::MemoryDumpManager::RegisterDumpProvider()          base/trace_event/memory_dump_manager.cc:362
base::trace_event::TraceLog::ctor()                                   base/trace_event/trace_log.cc:368
base::Singleton<>::get()                                              base/memory/singleton.h:258
base::trace_event::EnableFilteringForPseudoStackProfiling()           base/trace_event/memory_dump_manager.cc:117
base::trace_event::MemoryDumpManager::EnableHeapProfiling()           base/trace_event/memory_dump_manager.cc:259
base::trace_event::MemoryDumpManager::EnableHeapProfilingIfNeeded()   base/trace_event/memory_dump_manager.cc:227
tracing::EnableStartupTracingIfNeeded()                               components/tracing/common/trace_startup.cc:23

Basically we have that story:
1. Create MemoryDumpManager instance
2. Try to EnableHeapProfiling() when TraceLog is not created yet, MemoryDumpManager's lock got acquired
3. Create TraceLog as a part or lazy singleton dereference
4. TraceLog calls MemoryDumpManager::RegisterDumpProvider() which also acquires MemoryDumpManager's lock
5. Deadlock

I think would be reasonable to poke TraceLog's singleton before EnableHeapProfiling().