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

[Core] Fix Race Conditions in CMsgSubscriber #1324

Merged
merged 3 commits into from
Jan 23, 2024

Conversation

KerstinKeller
Copy link
Contributor

  • Properly implement destructor (in inherited classes)! -> Destroy may not be called in base CMsgSubscriber class as this can lead to stack unwinding (most likely causes an exception in destructor, or leads to already deleted functions of derived class being called when they are already deleted)
  • Correct order of RemReceiveCallback and resetting internal pointer
  • protect function pointer with mutex.
  • Make testcase "harder" to more easily trigger race conditions.

Cherry-pick to

  • 5.11 (old stable)
  • 5.12 (current stable)

- Properly implement destructor (in inherited classes)! -> Destroy may not be called in base CMsgSubscriber class as this can lead to stack unwinding (most likely causes an exception in destructor, or leads to already deleted functions of derived class being called when they are already deleted)
- Correct order of RemReceiveCallback and resetting internal pointer
- protect function pointer with mutex.
- Make testcase "harder" to more easily trigger race conditions.
Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

clang-tidy made some suggestions

@@ -125,7 +125,8 @@ namespace eCAL
return *this;
}

virtual ~CMsgSubscriber() {}
virtual ~CMsgSubscriber()
Copy link
Contributor

Choose a reason for hiding this comment

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

warning: use '= default' to define a trivial destructor [modernize-use-equals-default]

ecal/core/include/ecal/msg/subscriber.h:128:

-     {}
+     = default;

@@ -219,9 +223,12 @@ namespace eCAL
**/
bool RemReceiveCallback()
{
bool ret = CSubscriber::RemReceiveCallback();
Copy link
Contributor

Choose a reason for hiding this comment

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

warning: variable 'ret' is not initialized [cppcoreguidelines-init-variables]

Suggested change
bool ret = CSubscriber::RemReceiveCallback();
bool ret = false = CSubscriber::RemReceiveCallback();

@@ -245,7 +252,11 @@ namespace eCAL
private:
void ReceiveCallback(const char* topic_name_, const struct eCAL::SReceiveCallbackData* data_)
{
MsgReceiveCallbackT fn_callback(m_cb_callback);
MsgReceiveCallbackT fn_callback;
Copy link
Contributor

Choose a reason for hiding this comment

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

warning: variable 'fn_callback' is not initialized [cppcoreguidelines-init-variables]

Suggested change
MsgReceiveCallbackT fn_callback;
MsgReceiveCallbackT fn_callback = 0;

@KerstinKeller
Copy link
Contributor Author

Fixes #1318

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

clang-tidy made some suggestions

@@ -245,7 +251,11 @@ namespace eCAL
private:
void ReceiveCallback(const char* topic_name_, const struct eCAL::SReceiveCallbackData* data_)
{
MsgReceiveCallbackT fn_callback(m_cb_callback);
MsgReceiveCallbackT fn_callback = nullptr;
Copy link
Contributor

Choose a reason for hiding this comment

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

warning: variable 'fn_callback' is not initialized [cppcoreguidelines-init-variables]

Suggested change
MsgReceiveCallbackT fn_callback = nullptr;
MsgReceiveCallbackT fn_callback = 0 = nullptr;

@FlorianReimold FlorianReimold added this to the eCAL 5.12.2 / 5.11.7 milestone Jan 23, 2024
@FlorianReimold FlorianReimold merged commit 2006200 into master Jan 23, 2024
14 checks passed
KerstinKeller added a commit that referenced this pull request Jan 25, 2024
- Properly implement destructor (in inherited classes)! -> Destroy may not be called in base CMsgSubscriber class as this can lead to stack unwinding (most likely causes an exception in destructor, or leads to already deleted functions of derived class being called when they are already deleted)
- Correct order of RemReceiveCallback and resetting internal pointer
- protect function pointer with mutex.
- Make testcase "harder" to more easily trigger race conditions.
KerstinKeller added a commit that referenced this pull request Jan 25, 2024
- Properly implement destructor (in inherited classes)! -> Destroy may not be called in base CMsgSubscriber class as this can lead to stack unwinding (most likely causes an exception in destructor, or leads to already deleted functions of derived class being called when they are already deleted)
- Correct order of RemReceiveCallback and resetting internal pointer
- protect function pointer with mutex.
- Make testcase "harder" to more easily trigger race conditions.
@KerstinKeller KerstinKeller deleted the feature/cmsg-subscriber-race-conditions branch January 25, 2024 18:08
FlorianReimold pushed a commit that referenced this pull request Jan 26, 2024
- Properly implement destructor (in inherited classes)! -> Destroy may not be called in base CMsgSubscriber class as this can lead to stack unwinding (most likely causes an exception in destructor, or leads to already deleted functions of derived class being called when they are already deleted)
- Correct order of RemReceiveCallback and resetting internal pointer
- protect function pointer with mutex.
- Make testcase "harder" to more easily trigger race conditions.
FlorianReimold pushed a commit that referenced this pull request Jan 26, 2024
- Properly implement destructor (in inherited classes)! -> Destroy may not be called in base CMsgSubscriber class as this can lead to stack unwinding (most likely causes an exception in destructor, or leads to already deleted functions of derived class being called when they are already deleted)
- Correct order of RemReceiveCallback and resetting internal pointer
- protect function pointer with mutex.
- Make testcase "harder" to more easily trigger race conditions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants