Bugzilla

First, I think the assumption is fine, at least currently:
- Only "samples" contain stacks that were collected by another thread (the Sampler thread), which suspends the target thread, reads its current registers including PC and SP, and then does the stack sampling from there.
- Other stacks in markers must have been collected by functions like `profiler_capture_backtrace_into` in the thread itself, in which case the leaf frames (including the stack-walker call) are removed, so we only have return addresses -- so hopefully the leaf PC should be just after that stack capture function was requested (e.g., after the add-marker function/macro), but I don't know if it's that useful?

So I'm setting this bug at P3.

With that said, I suppose it would be good to add explicit information about this.

And I think it would be perfect to combine this with bug 1465869, in which we wanted to add per-frame type information.
So instead of the "stackNudging" suggestion, each frame would have one extra field indicating its exact type, one of (I think) : native leaf, native return, js, jit, label. Also Java? And importers could add languages they handle, e.g. Python.

And eventually this could also help tackle bug 1683040: I'm thinking that if sampling goes wrong, we could insert frames of a new type, with information about the sampling issue. For example, if a stack is too big to fit in our storage, the root frame would be something like "Incomplete backtrace", which I think would be less misleading than just a stack starting in a random function.

This feels simpler to me, and more flexible. What do you both think?

First, I think the assumption is fine, at least currently:
- Only "samples" contain stacks that were collected by another thread (the Sampler thread), which suspends the target thread, reads its current registers including PC and SP, and then does the stack sampling from there.
- Other stacks (in markers, etc.) must have been collected by functions like `profiler_capture_backtrace_into` in the thread itself, in which case the leaf frames (including the stack-walker call) are removed, so we only have return addresses -- and hopefully the leaf PC should be just after that stack capture function was requested (e.g., after the add-marker function/macro), but I don't know if it's that useful?

So I'm setting this bug at P3.

With that said, I suppose it would be good to add explicit information about this.

And I think it would be perfect to combine this with bug 1465869, in which we wanted to add per-frame type information.
So instead of the "stackNudging" suggestion, each frame would have one extra field indicating its exact type, one of (I think) : native leaf, native return, js, jit, label. Also Java? And importers could add languages they handle, e.g. Python.

And eventually this could also help tackle bug 1683040: I'm thinking that if sampling goes wrong, we could insert frames of a new type, with information about the sampling issue. For example, if a stack is too big to fit in our storage, the root frame would be something like "Incomplete backtrace", which I think would be less misleading than just a stack starting in a random function.

This feels simpler to me, and more flexible. What do you both think?