OMNeT++: Different results in 'fast' or 'express' mode

Question

Used Versions: OMNeT++ 5.0 with iNET 3.4.0

I created some code, which gives me reliable results in ‘step-by-step’- or ‘animated’ simulation mode. The moment I change to ‘fast’ or ‘express’ mode, it gets buggy. The following simplified example will explain my problems:

---

    void MyMacSlave::handleSelfMessage(cMessage *msg)
{
    if (msg == CheckAck) {
         std::cout << “CheckAck: “ << msg << std::endl;
    }

    if (msg == transmissionAnnouncement) {
         std::cout << “transmissionAnncouncement: “ << msg << std::endl;
    }

    if (msg == transmissionEvent) {
         std::cout << “transmissionEvent: “ << msg << std::endl;
    }

    delete msg;
}

There is a function, which is called for handling self-messages. Depending on what self-message I got, I need to run different if queries.

I get this correct output in step-by-step or animated mode:

CheckAck: (omnetpp::cMessage)CheckAck
transmissionAnncouncement: (omnetpp::cMessage)transmissionAnncouncement
transmissionEvent: (omnetpp::cMessage)transmissionEvent

And this is the strange output I get using fast or express mode:

CheckAck: (omnetpp::cMessage)CheckAck
transmissionAnncouncement: (omnetpp::cMessage)transmissionAnncouncement
transmissionAnncouncement: (omnetpp::cMessage)transmissionEvent
transmissionEvent: (omnetpp::cMessage)transmissionEvent

The third output line shows that the self-message is ‘transmissionEvent’, but the ‘if (msg == transmissionAnnouncement)’ is mistakenly considered as true as well.

---

As shown above I get different simulation results, depending on the simulation mode I am using. What is the reason for the different output? Why is there even a difference?

Answer 1

As Christoph and Rudi mentioned there was something wrong with the memory allocation. When a pointer is de-allocated and a new one is allocated on the same memory, there will be something wrong. The difference regarding the usage of different running modes is just a sign that there are errors to that effect.

In my case it was useful to check for message-kinds like:

if (msg->getKind() == checkAckAckType) {

instead of the method used in the originally question. I defined the message-kinds using simple enums.