Currently, if something goes wrong during sampling (system call error, too-big stack, etc.), the sample stays empty.

It would be great if we could record the reason for the failure so that it's visible in the profile.

In case of big stacks, maybe we could have a cut-off, and record an extra label frame to show the cut.

Bug 1761166 has an interesting profile: https://share.firefox.dev/3iOhrmd
One process is full of long gaps with no samples and no (or few?) markers.

It would be really useful in these cases if the profiler could record sampling failures, in case that's the problem.

Other potential culprits that would be worth recording:

• Some lock is kept for a long time, and blocks the sampler. -> Record long locking times in the sampler loop.
• The buffer gets full too quickly, and everybody is waiting for a new chunk to get allocated. -> Record chunk allocations (when they're first requested, then how long to fulfill them, and record whoever is waiting for them.)