Message id record does not store duplicate ids

[thomassedlmayer]

Currently, record_message_ids(..) tries to record all identifiers per frame. The function uses a dictionary (id_message_map) to store the identifier as key and the corresponding protobuf message as value. The issue here is that duplicate identifiers are not stored in the dictionary but every new object with a recurring identifier just overwrites an existing one with the same identifier. So the is_globally_unique rule (which is evaluated after id_message_map is written) will never evaluate to false. Additionally, the refers_to rule can not be evaluated properly. refers_to should probably evaluate to true if there is a correct object with the given identifier even if there are other objects as well? Currently, the result depends on the order in which the objects are defined.

We should refactor record_message_ids(..) to also store duplicate identifier entries.

[thomassedlmayer]

I have to take back the part about the is_globally_unique issue: It does work to some extent, I just didn't find the issues in the result file and then misunderstood the code. It just does not find ALL duplicate identifiers, e.g. if there are more than 2 types of objects with the same id. In that case, it only finds one id clash which is probably okay.

[pmai]

@thomassedlmayer yes and no, in that the is_globally_unique check does, as you say find id clashes, but not necessarily all of them, as this depends to some degree on the order of multiple ids clashes: So in certain probably rare circumstances, it might not find any clash, if the duplicate messages do not have an is_globally_unique rule, and by accident the only message that does have the rule happens to have its ID recorded last.

The only alternative would be to record all duplicated messages, which might be costly performance wise, for potentially not that much gain (as we are already seeing the problem that finding all issues tends to be costly for long-running traces in any case).

Should be discussed.