Detecting single process mode is impossible in //base so far, so the fix would not be simple.

I think there are some ways to fix this bug.

1. Enable to detect single process mode in //base
2. Make TraceLog::GetInstance()->process_id() unique between browser and renderers even in single process mode (process IDs are now used to generate dumps' GUID)
3. Change the way to generate dump IDs not to use process ID
4. Remove DCHECK in PMD::AddOwnershipEdges

3 sounds nice but I don't know how critical dump ID generations need to use process IDs . What do you think?

To clarify, let's say I'm not using single process mode, but instead duplicate a shared memory region and use it in the same process. We'll still see the same problem right?

It seems like the problem isn't related to single process mode, but rather to the way that we dump multiple instances of a shared memory region in a single process.

When we dump, we probably want to make an unordered_map of all GUIDs, and then should not emit the same GUID twice from the same process.

primiano, thoughts?

Hmm, this is not a minor problem but a real problem to pass for some browser tests:

https://chromium-review.googlesource.com/c/557741/
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_tsan_rel_ng/builds/107523

Re #4: I remember discussing this and we knew upfront this is a case we want to support because there are definitely sporadic cases of shm used within the same process (I.e when the browser process uses base::DiscardableMemory, or on Android low end where the gpu process is fused with the browser process ) 
I thought the guid code can already support this case after ssid created that createoverridableedge in base::Trace_event. 
I am out for the day and don't have anything more than a phone to cs. 
My suggestion is to ping ssid, I think we already have all the building blocks we need to support this. 
Of this turns out to not be the case I'll get on this on Monday. 

I do not understand why you would need to detect single process mode. Just removing the DCHECK should solve the problem. Yes it's my bad, I didn't think about single-process / memory shared in same process when adding the dcheck.

In such a case of memory shared in same process, this is what happens:

Tracker:
  auto* d1 = pmd->CreateAllocatorDump("shared_memory/seg1");
  d1->AddScalar("size", "bytes", 1024 *1024);
  auto* g1 = pmd->CreateSharedGlobalAllocatorDump(MemoryAllocatorDumpGuid(1));
  pmd->AddOverridableOwnershipEdge(d1->guid(), g1->guid(), 0);

Browser client:
  auto* c1 = pmd->CreateAllocatorDump("gpu_client/seg1");
  c1->AddScalar("size", "bytes", 1024 *1024);
  pmd->AddOwnershipEdge(c1->guid(), d1->guid());
  pmd->AddOwnershipEdge(d1->guid(), g1->guid(), 2);

Renderer client:
  auto* c2 = pmd->CreateAllocatorDump("cc_client/seg1");
  c2->AddScalar("size", "bytes", 1024 *1024);
  pmd->AddOwnershipEdge(c2->guid(), d1->guid());
  // This would DCHECK, if this comes after the previous provider in same process.
  pmd->AddOwnershipEdge(d1->guid(), g1->guid(), 0);  
  
If the DCHECK is removed, the code should work fine, except that the memory is shared equally between the clients and the importance is not respected. I am fixing the edge between the client and local_shm_dump to also contain importance so that it works correctly in single process mode.

So 2 edges will become:
  pmd->AddOwnershipEdge(c1->guid(), d1->guid(), 2);
  pmd->AddOwnershipEdge(d1->guid(), g1->guid(), 0);
This does not affect how multi process works.


Now, we already do not create multiple dumps in SHM tracker by checking GetAllocatorDump() before creating new one.
So, why do we need to detect single process in the tracker or in base.
Is there any more reason to change how the GUID is created for dumps (using PID). It is still essential?

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

commit f251d6591f25c3b769e47aee16f82ffabafb19b0
Author: Siddhartha <ssid@chromium.org>
Date: Fri Jul 07 11:44:51 2017

memory-infra: Allow creation of multiple edges between same allocator dumps

In single process mode, the SharedMemory clients will try to create
multiple edges between same global dumps. Fix the DCHECK.
For single process mode, the global dumps do not help and the importance
has to be added directly to the client dump edges.

BUG= 737885 

Change-Id: Id8636cc3442cdf7586995ba43b6a9bd068374385
Reviewed-on: https://chromium-review.googlesource.com/558388
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@chromium.org>
Commit-Queue: Hajime Hoshi <hajimehoshi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#484889}
[modify] https://crrev.com/f251d6591f25c3b769e47aee16f82ffabafb19b0/base/trace_event/process_memory_dump.cc
[modify] https://crrev.com/f251d6591f25c3b769e47aee16f82ffabafb19b0/base/trace_event/process_memory_dump_unittest.cc

I think this is fixed