Update on my investigations:

I believe that this has to do with SharedMemory and specifically the function CreateSharedMemoryOwnershipEdgeInternal. The issue seems to be that the local shared memory dump is not being created. Specifically the comment:

"Do not need to create the dumps here since the tracker would create them."

in the code does not seem to hold for all memory dump providers. An example of such a provider is BrowserGpuMemoryBufferManager where I see this behaviour. There does not seem to be any code in either that provider nor the tracker code which it calls to create a dump as would be expected.

ssid@ I think you set up the shared memory graph code: any ideas of why this issue is occurring?

+hajimehoshi because he has worked extensively on shared memory stuff.

Some more info: it seems like the SharedMemoryTracker only tracks memory when shared memory is mapped into the address space of the process and NOT when it is simply created. However, the key point is that some classes like BrowserGpuMemoryBufferManager sometimes only create the address space and then add an edge indicating that the memory is mapped.

From what I understand, we need to do one of the following:
1. Not add the edge if the memory is not mapped - this doesn't seem right to me though.
2. Track even when memory is created but not mapped. Not sure how this will cascade though so would appreciate some thoughts.

Okay to begin with the issue, I think we should support edges with no dump. There is a basic problem with memory dump providers being async and we need to create edges from one provider to other. There will always be cases where memory got cleared between 2 OnMemoryDump calls. It is easy to end up in a situation where the dumps do not exist, but we have edges.

Ideally what should happen is:
1. If the source dump is missing, then we just have extra memory present in the target. The effective size will just be attributed to the target.
2. If the target dump is missing, then the effective size of the target dump should be marked 0, since the source of the dump is missing.

But: we also have this other case where we sub-allocate instead of add ownership edge. This causes a sub-allocation created under a target dump. In this case the source and target will never be missing, but it is possible that the target memory usage was recorded before the source allocation happened. This causes the sub-allocation to be larger than the source itself. Currently we deal with this with increasing the size of the target to a higher value.
We cannot do the same thing for the previous case of missing dump where we do not know what the target is to increase the memory. Since in this case we make the effective size of the source = size, let's be consistent here and for the case 2 above and make the target dump effective size = size instead of 0.

For the case of gpu provider i filed issue 770857

> 2. If the target dump is missing, then the effective size of the target dump should be marked 0, since the source of the dump is missing.

I couldn't understand this sentence. What is missing is the target, not the source?

I understand case 1 but like hakimehoshi@ I'm confused about your points on case 2. Could you please clarify? Thanks!