-
Notifications
You must be signed in to change notification settings - Fork 128
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
Development/messageunit #1714
base: master
Are you sure you want to change the base?
Development/messageunit #1714
Changes from 49 commits
c33741b
3793120
1f58b65
3eb94a9
0674ec8
dd920b9
c9156cb
5e55df6
9579773
8bc4c8a
22e7e3b
346fb6e
3696efa
7c9a286
a7ef6b2
3737343
3453693
da8760c
c84512f
9c470c7
be5e514
5339888
7a25695
d34ded1
da02a32
f075681
5248a4b
ce9ead1
93ada9a
cdc50b2
3e16646
798b280
3329f27
71fec8a
24dbdfc
90f3519
9154bdd
6fc8f74
b4f620e
a746f7b
7c19e8f
aabbbbc
1a53ac8
8790fb8
45c1a99
3aeb751
131da15
3935b0e
5754339
c95399c
e4cdd8e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -51,11 +51,10 @@ ENUM_CONVERSION_END(Core::Messaging::Metadata::type) | |
{ | ||
_adminLock.Lock(); | ||
|
||
while (_controlList.size() > 0) { | ||
VARIABLE_IS_NOT_USED auto& control = *_controlList.front(); | ||
for_each (_controlList.begin(), _controlList.end(), [this](VARIABLE_IS_NOT_USED Core::Messaging::IControl* const & control) { | ||
TRACE_L1(_T("MessageControl %s, size = %u was not disposed before"), typeid(control).name(), static_cast<uint32_t>(_controlList.size())); | ||
_controlList.front()->Destroy(); | ||
} | ||
); | ||
|
||
_adminLock.Unlock(); | ||
} | ||
|
@@ -157,9 +156,9 @@ namespace Core { | |
{ | ||
uint16_t length = 0; | ||
|
||
ASSERT(bufferSize > (sizeof(_type) + (sizeof(_category[0]) * 2))); | ||
ASSERT(bufferSize > (sizeof(_type) + _category.size() + 1)); | ||
|
||
if (bufferSize > (sizeof(_type) + (sizeof(_category[0]) * 2))) { | ||
if (bufferSize > (sizeof(_type) + _category.size() + 1)) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct me if I am wrong but as far as I understand, in the Before we had
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I cannot correct you because I do not know the answer. I am not the original author of the code. What I noticed was that the test failed and length in Serialize() is given by https://github.com/rdkcentral/Thunder/blob/development/messageunit/Source/core/MessageStore.cpp#L130. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see, what I think is that Instead of using it, maybe it would be better to just check if On the other hand, perhaps it would be even better to only keep the ASSERT and remove this condition altogether @sebaszm? |
||
Core::FrameType<0> frame(const_cast<uint8_t*>(buffer), bufferSize, bufferSize); | ||
Core::FrameType<0>::Reader frameReader(frame, 0); | ||
_type = frameReader.Number<type>(); | ||
|
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
@@ -97,6 +97,8 @@ namespace Thunder { | |||||||||
public: | ||||||||||
void Handle(Core::Messaging::IControl* control) override | ||||||||||
{ | ||||||||||
ASSERT(control != nullptr); | ||||||||||
|
||||||||||
const string& module = control->Metadata().Module(); | ||||||||||
if (std::find(_modules.begin(), _modules.end(), module) == _modules.end()) { | ||||||||||
_modules.push_back(module); | ||||||||||
|
@@ -312,7 +314,6 @@ namespace Thunder { | |||||||||
Messaging::ConsoleStandardOut::Instance().Close(); | ||||||||||
} | ||||||||||
Core::Messaging::IStore::Set(nullptr); | ||||||||||
Core::Messaging::IControl::Iterate(handler); | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here it also looks like we are getting rid of a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You might recall the discussion outside the Github context about the ANNOUNCE-macros and elements initially added do not re-appear on open-close-open of MessageUnit. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See cdc50b2 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see, but it looks to me that if we drop this Iterate() and thus Destroy(), the other side (e.g. here) will not be aware that MessageUnit has been closed and its controls should no longer be used There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You (@VeithMetro) mentioned the use case is not what had been considered in the original design. However, from the tests it can be concluded that is a defect iff allowed. Imho allowing an explicit Close (https://github.com/rdkcentral/Thunder/blob/development/messageunit/Source/messaging/MessageUnit.h#L1007) suggests the code flow is allowed. A more recent test illustrates no current issue by re-adding the Destroy(). However, the code is not reached in any of the current tests (anymore). I suggest for now it is best to revert the removal of Destroy() and see what the future brings, or, try to implement a test which deliberately can excite that code point. What is your opinion? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think having a test which deliberately can excite that point in code, and which preferably suits a real use case would be great. Have you maybe tried to run Thunder to see if the Close() is ever executed? E.g. when closing MessageControl or other plugins which use messaging? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Any object that derives from IControl that is passed via Announce ( Thunder/Source/core/MessageStore.h Line 135 in 200249e
Thunder/Source/core/MessageStore.h Line 136 in 200249e
Thunder/Source/core/MessageStore.cpp Line 57 in 200249e
Thunder/Source/core/MessageStore.cpp Line 93 in 200249e
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed, that's why in messaging we make sure that a control will always be Revoked() (here) thus removed from our |
||||||||||
|
||||||||||
_adminLock.Lock(); | ||||||||||
_dispatcher.reset(nullptr); | ||||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we dropping
Destroy()
here?I tried to produce a scenario in which the
_controlList
was not clearly properly and thisTRACE_L1
was shown, and I couldn't get to that point, but I think at least in theory it is still possible, right?In that case, I think that the removal of
Destroy()
might lead to a segmentation fault as this destructor is the consequence of MessageUnit being destructed, thus messages should no longer be sentThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It actually caused a pure virtual function call fault - at the time of writing. See cdc50b2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is a similar situation to #1714 (comment). If we destory the whole Controls class which stores all
IControl
objects inControlList
, then it feels necessary to notify the other side about this fact, to make sure it won't try to perform any more traces, syslogs, etc. on these controls