-
Notifications
You must be signed in to change notification settings - Fork 96
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
ex_MQ_serialization1
should be stricter
#1286
Comments
fix part of FairRootGroup#1286: The result of ROOT's deserializer should be checked.
fix part of FairRootGroup#1286: The result of ROOT's deserializer should be checked.
fix part of #1286: The result of ROOT's deserializer should be checked.
fix part of FairRootGroup#1286: The result of ROOT's deserializer should be checked. (cherry picked from commit edb7657)
Can we close this, once #1325 is merged? |
Hm, as you wish. The proposed fix, however, does not really understand why there are non-deserializable messages. So, in this aspect the example is still broken. One could make the argument that it should continue to fail (although preferably not via a nullptr deref ;) which is fixed now) |
Good point. Well, in theory the thing should check for "all messages were received that were expected". So in that regard the thing is probably also broken. Retitled to follow the new target of this issue. Hope that's okay for you for the time being? |
ex_MQ_serialization1
(deref of nullptr
)ex_MQ_serialization1
should be stricter
Possibly #1295 is related. For now I'll assume it is the same underlying issue. I don't see any issue in the example devices.
What "thing"? The test checks for the So, I think the issue is either in the data generation, or in the ROOT serializer. I cannot judge what the data generation is doing - it was written by Nicolas 9 years ago and from a brief look I have no idea how it works. To narrow it down I propose to run the same algorithm which is done by the processor, also in the Sampler. That way if Sampler also crashes we will know that data generation is at fault. And if only the Processor keeps crashing - then it has to be de-/serialization. If data generation is at fault, we either debug it further or replace it with something simpler - since it is not the purpose of this example to do anything special on the generation side. if the generation code is valueable, it should be extracted to its own example. |
thing := the test. I had assumed, that we don't have enough checks in place. My fault! Please excuse me. That said, I am no longer sure, what the target of this issue currently is. |
I've seen the checks that you've added in the example, and they may surely help to avoid the crash. |
Closing as the examples had been rewritten in #1341 . |
Logs: https://cdash.gsi.de/testDetails.php?test=12812982&build=356755
Another line that looks suspicious is:
The text was updated successfully, but these errors were encountered: