-
Notifications
You must be signed in to change notification settings - Fork 411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Processor functions order lead to problems with timestamps #3820
Comments
I think we can do something like AllBefore and AllAfter, explicit and gets the point across. |
This is possible and will solve the current issue (I guess you mean "before all processors" by the |
Recently I thought about pushing the time normalization to the sink stage. |
If #3726 is implemented, I don't think there is a need as well. |
Processor functions can use the |
Description
Recently we changed the pipeline to have the
processEvent
stage, in which processor functions are called for the specific event.We added support there for processor functions which are applied to all events, and used the
normalizeEventCtxTimes
this way.However, this introduced some difficulties.
The processor functions for all events are called only after all the specific events processor functions are called.
This means that no processor function can use the timestamps as they are still monotonic (instead of absolute since epoch).
An example for a place struggling with it is the processor for
sched_process_exec
which creates the capture exec files. It uses the timestamp for the files captured, so since the change the times are not useful anymore.This is not the only place which struggles with this.
We should introduce a mechanism for assigning processor functions both before after the time fix, according to their need.
I guess that in the future we can expect more problems like this caused by ordering.
Output of
tracee version
:Output of
uname -a
:Additional details
The text was updated successfully, but these errors were encountered: