Processes with recycled PIDs are lost

[mstange]

Testcase: https://profiler.firefox.com/from-url/https%3A%2F%2Fgist.githubusercontent.com%2Fmstange%2F6c77ac541d596790f71249cd7c350fb8%2Fraw%2Ffbf70c9e5cd18454c02e356cc618b161ae72b15a%2Fcargo_cargo_query-api.profile.json/ There should be 3 processes with 4 threads in total, but only one process and a total of two threads is displayed.

In profiles that have multiple processes with the same PID, only one of them survives. The others are lost.

Re-used PIDs can occur if one process execves into another process without forking first. So it "becomes" the new process. One might argue that these processes should share the same track. But they have different names, so I think it makes sense to have them as separate tracks / threads / processes in the JSON.

The profile above was captured using perfrecord on cargo run. The cargo process "becomes" the executable that it wants to run.

Here's the structure of the profile linked above:

{
  "meta": {
    ...
    product: "cargo",
    pid: 60548,
    ...
  },
  subprocesses: [
    {
      "meta":  {
        ...
        product: "cargo",
        pid: 60548,
        ...
      },
      ... (2 threads)
    },
    {
      "meta":  {
        ...
        product: "query-api",
        pid: 60548,
        ...
      },
      ... (1 thread)
    }
  ],
  ... (1 thread)
}

[julienw]

Ah, this is unfortunate, indeed we have a bunch of locations where we use the pid as a key (mostly everything related to local tracks).

[mstange]

I can fix this on the generator side by producing unique pids. I will add suffixes like ".1" and ".2". In #4459 I am making it so that string pids become usable for this.

[mstange]

Fixed to my satisfaction by #4506.