[tracing] Send unique tracing process id for cross-process memory dumps identification.

components/tracing/child_trace_message_filter.cc

Index: components/tracing/child_trace_message_filter.cc
diff --git a/components/tracing/child_trace_message_filter.cc b/components/tracing/child_trace_message_filter.cc
index ad34a24c352cd6105797c8914977c79451ab50d1..40144fbade45498baaf31595b2526f9aff664185 100644
--- a/components/tracing/child_trace_message_filter.cc
+++ b/components/tracing/child_trace_message_filter.cc
@@ -4,6 +4,7 @@
 
 #include "components/tracing/child_trace_message_filter.h"
 
+#include "base/trace_event/memory_allocator_dump_guid.h"
 #include "base/trace_event/trace_event.h"
 #include "components/tracing/child_memory_dump_manager_delegate_impl.h"
 #include "components/tracing/tracing_messages.h"
@@ -58,7 +59,8 @@ ChildTraceMessageFilter::~ChildTraceMessageFilter() {}
 
 void ChildTraceMessageFilter::OnBeginTracing(
     const std::string& trace_config_str,
-    base::TraceTicks browser_time) {
+    base::TraceTicks browser_time,
+    int child_process_id) {

[dcheng, 2015/06/20 00:36:27]

I'm a bit confused: it looks like in the previous issue, we didn't want to send
the process ID to the child? Does this code run in the browser process?

[Primiano Tucci (use gerrit), 2015/06/20 12:32:31]

In the previous issue turned out we didn't want to "expose" the child process id
(because clients might cache it, use it for futher child->browser IPC, and
somebody might end up relying and trusting that).
The deal was to send it but never expose it (keep it internal to expand the $$
string).
See John's comment on goo.gl/ncMfUV.

(Not sure why ssid@ switched reviewer instead of keep following up with John who
was in the loop in the first discussion.)

[ssid, 2015/06/20 13:07:24]

Yes, as primiano pointed out, the issue was only not to expose the id. Here
instead of exposing it is stored at the file which requires the id and used
directly.

I added dcheng@ for the components/tracing/tracing_messages.h file, since jam@
wasn't the owner. I mentioned in comment :)

[jam, 2015/06/22 16:20:14]

My reading of the previous discussion was that the ID wouldn't be sent to the
child process, instead some hash. For the same reasons as I mentioned earlier,
we shouldn't send the process id to the child process, even if it's not
(currently) being exposed.

 #if defined(__native_client__)
   // NaCl and system times are offset by a bit, so subtract some time from
   // the captured timestamps. The value might be off by a bit due to messaging
@@ -66,6 +68,8 @@ void ChildTraceMessageFilter::OnBeginTracing(
   base::TimeDelta time_offset = base::TraceTicks::Now() - browser_time;
   TraceLog::GetInstance()->SetTimeOffset(time_offset);
 #endif
+  base::trace_event::MemoryAllocatorDumpGuid::SetUniqueChildProcessId(
+      child_process_id);
   TraceLog::GetInstance()->SetEnabled(
       base::trace_event::TraceConfig(trace_config_str),
       base::trace_event::TraceLog::RECORDING_MODE);
@@ -80,6 +84,9 @@ void ChildTraceMessageFilter::OnEndTracing() {
   // OnTraceDataCollected calls will not be deferred.
   TraceLog::GetInstance()->Flush(
       base::Bind(&ChildTraceMessageFilter::OnTraceDataCollected, this));
+
+  base::trace_event::MemoryAllocatorDumpGuid::SetUniqueChildProcessId(
+      base::trace_event::MemoryAllocatorDumpGuid::kInvalidChildProcessId);
 }
 
 void ChildTraceMessageFilter::OnEnableMonitoring(