We just realized that the https://codereview.chromium.org/2386123003/ broke the memory-infra heap profiler on Android (but I think also on Linux and Windows) on non-official builds.

Fortunately it's really a minor thing, the breakage is simply hitting the paranoid   DCHECK(CalledOnValidThread()) in base/allocator/allocator_shim.cc when calling InsertAllocatorDispatch.

The crash happens when building in debug (or dcheck_always_on=true). Essentially the following is happening:
The aforementioned CL introduced the following change:

buildflag(ENABLE_MEMORY_TASK_PROFILER) == enable_memory_task_profiler ==  use_experimental_allocator_shim && !is_official_build
Which is true by default on non-official builds of all platforms % OSX/iOS.

ThreadData::InitializeThreadContext() is called from some thread (whatever comes first)
It calls into ThreadData::EnsureTlsInitialization()
Which does:
#if BUILDFLAG(ENABLE_MEMORY_TASK_PROFILER)
  ...
    base::debug::ThreadHeapUsageTracker::EnableHeapTracking();
  ...
#endif
Ultimately EnableHeapTracking() calls base::allocator::InsertAllocatorDispatch(...)

So the problem here is that InsertAllocatorDispatch is called from a somewhat arbitrary thread. Which would be fine % the fact that when we use --enable-heap-profiling, we also call InsertAllocatorDispatch() (from the main thread, IIRC).

The two threads don't match and we end up hitting that DCHECK (thanks primiano-from-the-past for putting it in place!)
We should make sure that both shim dispatches (memory-infra and heap profiler) are always register on the same thread. The current code is racy.

Unfortunately didn't spot this while revieweing crrev.com/2386123003

P.S. this kind of breakage would be caught if we had fixed  Issue 670828  (write a browser test for tracing with --enable-heap-profiling)