[Messaging] ASSERTS as a new Messaging stream #1822
Conversation
…ere moved to core
… other necessary components
…ssage, both used not only in Messaging, but now also in core for the Asserts
… under Messaging section
…er starts, just like in case of WarningReporting
…y get Asserts configs
…s which do not link plugins
…s external it is based on that class
…om the scope of Thunder::Messaging
…/Thunder into development/messaging-asserts
Source/core/MessageStore.cpp
Outdated
| if (length != 0) { | ||
| const uint16_t extra = static_cast<uint16_t>(sizeof(_processId) + (_processName.size() + 1) + (_fileName.size() + 1) + sizeof(_lineNumber) + (_callstack.size() + 1)); | ||
|
|
||
| ASSERT(bufferSize >= (length + extra)); |
There was a problem hiding this comment.
Wondering what happens when ASSERT() happens during processing of an assert?
There was a problem hiding this comment.
Depends, if we are talking about Debug and having abort in the ASSERT macro, then I suppose we would only get this ASSERT in the buffer and not the "original" one, since we would abort right after the bufferSize >= (length + extra) ASSERT, so before the original one can be put into the buffer
There was a problem hiding this comment.
It seems to me that ASSERTs on serialize path have non-zero chance of endless recursion and need to be removed (maybe replaced with TRACE_L1 for some sign of the double fault happening) and if needed the assert situation guarded by a condition statement instead.
@sebaszm correct, the chance of an endless recursion was definitely not zero - if an another ASSERT happened before the original ASSERT was fully serialized, then we could end up with an endless recursion.. To handle that, I replaced each ASSERT on the messages serialization path with a new macro |
…on path to avoid endless recursions
|
|
||
| AssertionUnitProxy::AssertionUnitProxy() | ||
| : _handler(nullptr) | ||
| , _adminLock(new Core::CriticalSection()) |
There was a problem hiding this comment.
Why can this not be a member (composit), Is there a real purpose to the new ?
There was a problem hiding this comment.
Never mind found the answer, forward declaration.
The idea behind these changes has been described more in this Jira ticket.
After this PR is merged, the second one to ThunderNanoServices will follow, which adjusts MessageControl accordingly. And then the same will apply to ThunderUI and other repos with some minor adaptations.