Thanks, will investigate.

I tried and failed to repro this. I can think of 2 possible causes:

1) I recently fixed 2 race-conditions that occur around the time of heap dumps that could cause the heap to never be dumped: https://chromium-review.googlesource.com/c/chromium/src/+/917243

2) The profiling process was backed up [for 5 minutes??] with allocations. Seems unlikely, but you can check by looking at CPU usage of profiling process.

If you have a repro, I'd like to try it out locally.

I looked into this and it seems this is issue with memory infra.
What happens is the process dump never finishes if some thread is busy doing stuff.
In my case 2 threads were busy: sync thread and indexeddb thread. These had like million tasks posted on them and posting memory-infra task on these threads just took too long to return. We might be able to do something like adding timeout for the threads to run the posted task or ignore the dump provider. But most times it turns out that the dump provider ignored is what we are interested in.

Back to the case of memlog. I guess gathering a report for a process waits for memory dumps to complete and the in-process dump does not have timeout and never completes.

Re memlog: I'm about to fix this, see https://chromium-review.googlesource.com/c/chromium/src/+/899963

Cool that should fix the issue of not having both heap dump and process dump when tracing.
q: What happens when I click "Save dump" on chrome://memory-internals. Does it wait for both the dumps to complete or times out on the request. Might be good idea to have timeout on memory-infra dump.