core(tracehouse): allow nested trace events without an end #9785
Conversation
| {ph: 'I', name: 'MarkerToPushOutTraceEnd', pid, tid, ts: baseTs + 110e3, args}, | ||
| // TaskB is missing an E event within an X | ||
| {ph: 'X', name: 'TaskA', pid, tid, ts: baseTs, dur: 100e3, args}, | ||
| {ph: 'B', name: 'TaskB', pid, tid, ts: baseTs + 10e3, args}, |
| {ph: 'X', name: 'TaskA', pid, tid, ts: baseTs, dur: 100e3, args}, | ||
| {ph: 'B', name: 'TaskB', pid, tid, ts: baseTs + 5e3, args}, | ||
| {ph: 'E', name: 'TaskB', pid, tid, ts: baseTs + 115e3, args}, | ||
| {ph: 'I', name: 'MarkerToPushOutTraceEnd', pid, tid, ts: baseTs + 200e3, args}, |
There was a problem hiding this comment.
some of these seem like they won't affect anything, is it just general hygiene so they're all similar?
There was a problem hiding this comment.
they actually do have a noticeable effect though because if the E is the traceEnd then we fall into a different error recovery mode that turns these into valid events which is not what we want to test
There was a problem hiding this comment.
added a comment to this effect
There was a problem hiding this comment.
they actually do have a noticeable effect though because if the
Eis the traceEnd then we fall into a different error recovery mode that turns these into valid events which is not what we want to test
oh right, because then it would be assumed TaskB didn't have an end event (even though it did) and one was created for it (even though one wasn't), so then it would get trimmed to the length of TaskA.
Doesn't that seem like a problem with using traceEndTs as the signal we were missing an end event? It seems like this case (before the MarkerToPushOutTraceEnd event is added) shouldn't be treated that way (even if it is very unlikely to occur).
Are there downsides to using Infinity for the ts in
?
There was a problem hiding this comment.
Doesn't that seem like a problem with using traceEndTs as the signal we were missing an end event? It seems like this case (before the MarkerToPushOutTraceEnd event is added) shouldn't be treated that way (even if it is very unlikely to occur).
I disagree. In the case where we have just one of the E events and no other events following it at all, the most likely explanation to me is that it just got cutoff emitting the other E event for the exact same time, i.e. the exact case our workaround is targeting.
The fact that other events follow it is what makes it a completely invalid situation.
There was a problem hiding this comment.
In the case where we have just one of the E events and no other events following it at all, the most likely explanation to me is that it just got cutoff emitting the other
Eevent for the exact same time, i.e. the exact case our workaround is targeting
Hmm, I don't understand. In the case of
{ph: 'X', name: 'TaskA', pid, tid, ts: baseTs, dur: 100e3, args},
{ph: 'B', name: 'TaskB', pid, tid, ts: baseTs + 5e3, args},
{ph: 'E', name: 'TaskB', pid, tid, ts: baseTs + 115e3, args},
clearly there was an end event emitted...it seems better to check if other invalid heuristics apply than to just chop off TaskB at baseTs + 100e3.
There was a problem hiding this comment.
Oh, oh sorry! Yeah this specific case sounds like it should work without it. 👍
There was a problem hiding this comment.
alright Infinity has it's own set of problems which is why I avoided it to begin with, so introduced an unbounded boolean to deal with this. LMK if you think it's worth the tradeoff in the latest commit
There was a problem hiding this comment.
alright
Infinityhas it's own set of problems which is why I avoided it to begin with, so introduced anunboundedboolean to deal with this. LMK if you think it's worth the tradeoff in the latest commit
I figured there must be dragons in Infinity, but it was worth a look :) unbounded isn't the most elegant looking, but IMO it's worth it.
| * @prop {LH.TraceEvent} event | ||
| * @prop {TaskNode[]} children | ||
| * @prop {TaskNode|undefined} parent | ||
| * @prop {boolean} unbounded |
There was a problem hiding this comment.
maybe put a note on this one to identify what it means?
| {ph: 'X', name: 'TaskA', pid, tid, ts: baseTs, dur: 100e3, args}, | ||
| {ph: 'B', name: 'TaskB', pid, tid, ts: baseTs + 5e3, args}, | ||
| {ph: 'E', name: 'TaskB', pid, tid, ts: baseTs + 115e3, args}, | ||
| {ph: 'I', name: 'MarkerToPushOutTraceEnd', pid, tid, ts: baseTs + 200e3, args}, |
There was a problem hiding this comment.
alright
Infinityhas it's own set of problems which is why I avoided it to begin with, so introduced anunboundedboolean to deal with this. LMK if you think it's worth the tradeoff in the latest commit
I figured there must be dragons in Infinity, but it was worth a look :) unbounded isn't the most elegant looking, but IMO it's worth it.
3 participants
Summary
Addresses one of the 3 remaining cases for
Fatal trace logic error - child cannot end after parenterror.Related Issues/PRs
#7764