Skip to content
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

Fix #494, Updates CFE_SB_GetLastSenderID to check if message has been sent on pipe #605

Merged
merged 1 commit into from
Apr 21, 2020

Conversation

dmknutsen
Copy link
Contributor

@dmknutsen dmknutsen commented Apr 13, 2020

Describe the contribution
Updates CFE_SB_GetLastSenderID to check if a message has been sent on the associated pipe prior to setting the receivers pointer to the associated address of 'sender' in the buffer descriptor.

Includes associated unit test addition to cover the additional path added to CFE_SB_GetLastSenderID.

Includes an addition of a SB status code and event ID.

Fix #494

Testing performed

  1. Ran unit tests.
  2. Reviewed coverage test results to ensure that additional path added is covered with the updated unit test.

Expected behavior changes
CFE_SB_GetLastSenderID will now detect if it is being called prior to a message being sent on a given pipe.

System(s) tested on
Oracle VM VirtualBox
OS: ubuntu-19.10
Versions: cFE 6.7.11.0, OSAL 5.0.9.0, PSP 1.4.7.0

Contributor Info
Dan Knutsen
NASA/Goddard

Copy link
Contributor

@jphickey jphickey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made some comments to specific code sections. Overall, it does seem this will handle the specific case of a segfault, but it will not handle the more fundamental issue with this API. We might need to discuss and possibly deprecate and replace.

*Ptr = (CFE_SB_SenderId_t *) &Ptr2BufDescriptor -> Sender;
CFE_SB_UnlockSharedData(__func__,__LINE__);
return CFE_SUCCESS;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, this API is fundamentally broken. I had never really looked at it before.

The content of CFE_SB.PipeTbl[PipeId].CurrentBuff is shared, and needs to be locked while accessing it. (which it is, within this function). But then it is gettng a direct pointer to the data within the descriptor, unlocking, and returning that pointer for the application to access. This is unsafe - that data can be overwritten at any time after the unlock.

Rather, this should take a pointer to the CFE_SB_SenderId_t buffer (not a pointer-to-pointer) and copy the data, then unlock.

Of course, this changes the API, and makes it incompatible.

One possible mitigation to make it backward compatible is to have a separate buffer in the PipeTbl struct holding another copy, then copy the data into that and return a pointer to it. That way at least the returned pointer would remain valid until the next call to the same function on the same pipe (sort of like the way the posix readdir issue was mitigated).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #608

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with the general philosophy. I just wanted to point out that the documentation does state that *Ptr is only valid until the next call to CFE_SB_RcvMsg for the same pipe.

** descriptor for the last msg received for a given pipe is NULL. This usually occurs because
** CFE_SB_GetLastSenderId was called prior to recieving a msg.
**/
#define CFE_SB_NO_LAST_MESG_RECV_EID 64
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this really warrant an "error event"? Seems like normal operational context - there is nothing inherently an "error" about a pipe that exists but hasn't been sent to yet.

I can foresee this API being used to simply check if a pipe has been written to or not, where so long as the application handles the return code its not an error either way, and generating an "Error event" might be confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just removed error event and pushed the updates.

Copy link
Contributor

@skliper skliper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixes the segfault, #608 separated

@skliper skliper added the CCB:Ready Ready for discussion at the Configuration Control Board (CCB) label Apr 14, 2020
@astrogeco astrogeco changed the title Fixes #494, Updates CFE_SB_GetLastSenderID to check if message has been sent on pipe Fix #494, Updates CFE_SB_GetLastSenderID to check if message has been sent on pipe Apr 14, 2020
@astrogeco
Copy link
Contributor

CCB 20200415 - APPROVED

@astrogeco astrogeco added CCB:Approved Indicates code review and approval by community CCB CCB - 20200415 and removed CCB:Ready Ready for discussion at the Configuration Control Board (CCB) labels Apr 20, 2020
@astrogeco astrogeco changed the base branch from master to integration-candidate April 21, 2020 22:18
@astrogeco astrogeco merged commit d9ade13 into nasa:integration-candidate Apr 21, 2020
@skliper skliper added this to the 6.8.0 milestone Jun 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CCB:Approved Indicates code review and approval by community CCB
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CFE_SB_GetLastSenderID will crash if if called before message sent on pipe
4 participants