PROFILER_MARKER_UNTYPED(..., MarkerStack::Capture()) compiles but doesn't capture a stack.
Categories
(Core :: Gecko Profiler, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox83 | --- | fixed |
People
(Reporter: emilio, Assigned: mozbugz)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
I tried to do it and got very confused... It should either not compile or error at runtime at least or something.
Per discussion in #profiler, this is because it doesn't carry a payload which is where the stack is stored.
I can use PROFILER_MARKER_TEXT
instead, though in my case I had no string to put there.
Assignee | ||
Comment 1•4 years ago
|
||
Ah yes, this is a current limitation of no-payload markers, I was hoping we would fix it soon enough in bug 1646714, but you're right that this is not a satisfying experience at the moment, sorry about that. I'll add a runtime check...
Assignee | ||
Comment 2•4 years ago
|
||
Note to self, an idea to explore: At runtime, if one of the options would be lost in a PROFILER_MARKER_UNTYPED
/NoPayload
marker, automatically convert it to a new NoPayloadUserData
marker that can carry the information. This way we won't need to re-convert fake Text
markers back to NoPayload
when bug 1646714 lands...
Assignee | ||
Comment 3•4 years ago
|
||
It is possible to add options to a NoPayload marker, but stack and inner window ids would be lost because they are normally stored in the payload 'data' JSON object, which doesn't exist for NoPayload markers.
So in this case, we automatically change the marker to a new (internal) "NoPayloadUserData" type, which has a payload in which we can store options.
This is temporary, until bug 1646714 moves these options into the top-level marker JSON object.
Assignee | ||
Updated•4 years ago
|
Pushed by gsquelart@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/aaddd4c00f6e If NoPayload marker has a stack and/or inner window id, convert to NoPayloadUserData - r=gregtatum
Comment 5•4 years ago
|
||
bugherder |
Description
•