To be more clear, the question is about the following line in https://codereview.chromium.org/2450073002/patch/80001/90002: 

var thread = process.getOrCreateThread(pid);

, where the signature of the called function should be process.getOrCreateThread(thread_id)

So we're actually using parsed pid from sched_switch event as the tid (thread_id) stored in the data structure.
This causes some unexpected issue.

For example, in the attached report in the issue, we have sched_switch event reported by kernel ftrace
ompositor-29073 (29066) [005] d..3  9224.2 sched_switch: prev_comm=Compositor prev_pid=29073 prev_prio=112 prev_state=S ==>next_comm=chrome next_pid=28356 next_prio=112

And we also have Chrome trace event in JSON format:
{"pid":29066,"tid":5,"ts":0,"ph":"M","cat":"__metadata","name":"thread_name","args":{"name":"Compositor"}},

In the end we have following data stored for process 29066 trace:

thread: {
     5: {"name": "Compositor"},
     29073: {"name": "Compositor"}
}

However, thread 29073 is not really a thread running in process 29066.

In chrome_renderer_helper.html, we expect there is only one thread name "Compositor" in Chrome trace event.

To fix this problem, can we simply add a prefix to the thread name from scheduling event? Any suggestion?

As I said in the internal bug Linux does not have a TID. Threads are identified by PIDs on Linux.

In this case it's the 29073 that's correct and the 5 that's "wrong". Or rather, 29073 is the OS identifier for the thread and 5 is some Chrome-internal identifier for the thread, thus the conflict.

Got your point. So the problem is why chrome is using internal identifier instead of using system call like gettid() or syscall(SYS_gettid);

Hi Nat,
Could you help on this or do you know who we can ask?

Un-CCing myself. Feel free to re-CC me if necessary.

Concerning #3. I would assume that the internal identifiers are cheaper to get. But I will have to look closer.

Also the assert in tracing.js seems new in M56+ as I can load the trace in M55 browser:

While importing:
Error: Expected no more than one Compositor
    at Process.findAtMostOneThreadNamed (chrome://tracing/tracing.js:2436:7)
    at ChromeRendererHelper (chrome://tracing/tracing.js:922:403)
    at ChromeModelHelper.<anonymous> (chrome://tracing/tracing.js:944:152)
    at Array.forEach (native)
    at ChromeModelHelper (chrome://tracing/tracing.js:944:101)
    at Model.getOrCreateHelper (chrome://tracing/tracing.js:2563:67)
    at ChromeAuditor (chrome://tracing/tracing.js:4758:431)
    at Import.<anonymous> (chrome://tracing/tracing.js:1336:430)
    at Array.map (native)
    at Import.createAuditorsAndRunAnnotate (chrome://tracing/tracing.js:1336:390)

Any update or anything we can help on this?

Reply for #8:
I think it's because CL https://codereview.chromium.org/2450073002 is merged after M56+.

Anyone looking at this? This sometimes blocks tracing on ARC++ now.