You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/* Indicate that "not registered" event has been sent for this app */
AppDataPtr->EventCount++;
The problem is that this is, by definition, invoked when the calling AppID is wrong (not registered), but it is changing a field that is also potentially used for valid (registered) AppIDs.
To Reproduce
This can theoretically occur if an app calls CFE_EVS_SendEventWithAppId() using an old AppID value, for instance if an app was restarted it gets unregistered, and then gets a different AppID but refs to the old value could still exist. The new AppID doesn't necessarily have the same slot in the table - in fact it shouldn't. The old table entry might refer to a totally different app.
So if this happens it will corrupt/change the EventCount member on an unrelated app data entry.
This can be seen in the EVS telemetry, where if the "unregistered" event occurs it inadvertently creates a nonzero AppMessageSentCounter in the TLM data on an unrelated app that happens to share that slot in the table.
Also, if the counter was already nonzero because the table entry is in use by another (registered) app then this prevents the notification about the unregistered app from appearing at all.
Expected behavior
Should not overload the EventCounter to track a basically unrelated item - which is whether or not an "unregistered" event occurred on a different app that happened to map to the same entry.
Simple fix would be to just introduce a separate field to track this.
System observed on:
Ubuntu 20.04
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered:
Do not use EventCount to track whether an "unregistered" event
was generated, because that by definition came from a different app
than the one that "owns" that field.
This just adds a separate field to track that state, so it doesn't
potentially modify the counter for an unrelated app.
Do not use EventCount to track whether an "unregistered" event
was generated, because that by definition came from a different app
than the one that "owns" that field.
This just adds a separate field to track that state, so it doesn't
potentially modify the counter for an unrelated app.
Describe the bug
The
EventCount
member of the EVS internal app data is intended to track the number of events sent by a particular app.BUT - it is also overloaded to track if the event came from the wrong app, here:
cFE/fsw/cfe-core/src/evs/cfe_evs_utils.c
Lines 187 to 194 in 983157d
The problem is that this is, by definition, invoked when the calling AppID is wrong (not registered), but it is changing a field that is also potentially used for valid (registered) AppIDs.
To Reproduce
This can theoretically occur if an app calls
CFE_EVS_SendEventWithAppId()
using an old AppID value, for instance if an app was restarted it gets unregistered, and then gets a different AppID but refs to the old value could still exist. The new AppID doesn't necessarily have the same slot in the table - in fact it shouldn't. The old table entry might refer to a totally different app.So if this happens it will corrupt/change the
EventCount
member on an unrelated app data entry.This can be seen in the EVS telemetry, where if the "unregistered" event occurs it inadvertently creates a nonzero
AppMessageSentCounter
in the TLM data on an unrelated app that happens to share that slot in the table.Also, if the counter was already nonzero because the table entry is in use by another (registered) app then this prevents the notification about the unregistered app from appearing at all.
Expected behavior
Should not overload the EventCounter to track a basically unrelated item - which is whether or not an "unregistered" event occurred on a different app that happened to map to the same entry.
Simple fix would be to just introduce a separate field to track this.
System observed on:
Ubuntu 20.04
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: