send methods create a copy of message which are never deleted

[Korbinian Grimme]

Hi,

i am still wondering to find nothing about this topic by searching with google several hours.

To get my ideas across to you i modified the tictoc-example code a bit (see attachment).

I inserted just methods to get some output while simulation is running. Even so i added a new message type 'OwnMessage' which is inherited from cMessage. In OwnMessage i just implemented a constructor, the copy constructor and the destructor. In these Methods do nothing but output.

If you run the example-simulation with the gui either "step-by-step" (execute-on-event, F4) , "normal" (run with full animation, F5) or "fast" (run faster: no animation and rare inspector updates, F6) you will see that every time the send method is called a new message (with new id) is created inside the send method. While the message id for the message which is delivered to the next module is always 0, the message id for the copy of that message is always a new one, higher than that before.

This is the correct behavior because every massage, even a duplication of that message, must have its own message id.

But why is send making a copy of the message. And why will that message never been deleted? The output (and even the gui) shows that they are never deleted.

If you run the simulation in "express" (run at full speed: no output, animation or inspector updates, F7) there is just one copy of the message made at the start of the simulation. After that the counter will always show 2 created messages.

Am i on the wrong track with my idea that this could be a memory leak?

Another problem i detected is that if you run the simulation "fast" and the count of message reaches 100000 the simulation tries to delete the original message which leads to a problem because this message is still being sent and received by the tictoc modules. If you run the simulation in express there is no such problem even if your simulation reaches message counts higher than 100000.

Because i did not find anything about that behavior in the manual or the documentation i hope that some of you know some answers that can help me to understand the problems.

Kind regards

Korbinian

[Korbinian Grimme]

No suggestions?

The Gerneral.log shows that even in "Express"-Mode copies of every message object are instanciated. I could not find anything about that behavior neither in documentation nor googling around several hours.

I do not understand why omnet instanciates copies of messages even if that copies are not sent or used.

Maybe some of you have an idea?

Greets

Korbinian

[jime]

I did not read what you wrote entirely. but as far as my knowledge - maybe wrong - when a message is exchanged between two modules, a "take()" method is called - or need to be called, which would transfer the owner of that message to the new module. in that case the message can't be deleted from the old module. sometimes you use msg->dup() in send function and you delete the message itself but not the duplicate.
another function related to message ownership is drop(), which releases ownership of the message.
I hope this could give you any indication to your problem.

[Korbinian Grimme]

Hi jime,

thanks for your response.

You are right. A module must be the owner to have the delete permission on the message object and ownership can be taken by calling take()-method.

Debugging with a breakpoint at the beginning of the copy-constructor shows me that stack trace (shortened)

LogBuffer::beginSend() at logbuffer.cc:156 0x7ffff7b0f619

Tkenv::beginSend() at tkenv.cc:1,262 0x7ffff7af5f60

cSimpleModule::sendDelayed() at csimplemodule.cc:423 0x7ffff6f6d2ba

Code in LogBuffer is responsible for copying the messages.

It makes a copy of the message and changes the ID of the copy (which has a new message-ID like mentioned before) to the id of the original message.

So the message passed to the next module is still the original message (compared the start addresses of the objects in debugger)

LogBuffer keeps duplicated message with original id. Why does it do so and why are that messages not deleted in slower running modes?

[Michael Kirsche]

Hi Korbinian,

that is indeed a very interesting behavior.
I didn't believe it at first, but your example shows it pretty good as does the normal TicToc example (the GUI clearly shows that the number of created and existing messages goes steadily up if you run the simulation in normal and fast mode).

I've did a quick check with some other examples like Aloha and I could confirm it.
Whenever a message is just being send and not deleted and created again, a copy is created and not deleted anymore.
Running the simulation in Express mode always lead the correct behavior -> number of messages created is growing but the number of messages present stays the same.
I could confirm the behavior with OMNeT 4.6 under Windows and OMNeT 4.5 under Linux.

The interesting thing is, I tried the same with an older OMNeT 4.3.1 installation under Linux and it shows the correct behavior (present messages stays the same, doesn't matter if you run the simulation in normal, fast or express mode).

I think you indeed found some important bug as this behavior is not normal/expected!
Thanks a lot for the initial pointer, I'll try to take a deeper look into and create a bug report on the OMNeT bug list!

[Varga, András]

Hi Korbinian and Michael,

Sorry to step in so late in the conversation, I totally overlooked the earlier messages. The behavior you discovered is normal (not a bug). It is Tkenv that duplicates the messages (in fact it stores a copy of each message sent), for a feature that was introduced in 4.5, during the Tkenv redesign.

In version 4.5, the "Log" view (bottom part of the Tkenv main window) has been improved significantly, and beyond the old "Log" page it also has a "Messages" page. The "Messages" page shows the messages sent within submodules of the selected compound module. Moreover, if you select a line in it, in the Object Inspector (bottom left) it will display the given message in detail. You can inspect every single field of it.  That's why Tkenv duplicates the sent messages -- it's needed for this feature.

I thought this feature was quite useful. You can virtually use the "Messages" view as a protocol analyzer, you can browse through the past traffic in that module at any time, and examine each message in detail.

You can configure the size of the event history (LogBuffer class as Korbinian discovered) in the Tkenv Preferences dialog. Old log entries are discarded, together with the duplicate of the old messages.

See the "7.5.6 The Log Viewer" in the User Guide (not the Manual) for some more details and nice screenshots :) http://www.omnetpp.org/doc/omnetpp/UserGuide.pdf

Sorry, I didn't mean to keep the feature secret, and I certainly didn't think it would cause trouble like this :)

Best,

Andras

--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Kirsche]

Hi Andras,

thanks for the clear-up.
I was experimenting with the code and was a bit worried that there's some serious bug there.

The Log Viewer is definitely new for me in the way that I didn't know that messages are duplicated for it (and stored). I though that you probably just used a log file with the message attributes/contents.

The feature is definitely useful, but I think that the simulation GUI should only show real messages still existing in the network/simulation.
I see those message copies in the log viewer as a kind of shadow messages. It can become confusing when you wonder why your number of created/existing messages is steadily increasing while you basically just re-send a single message that you've created.

Is there an easy way to remove the "shadow messages" (the copies for the log viewer) from the statistics in the simulation GUI?

Best wishes,
Michael

[Korbinian Grimme]

Not only the message counter in the GUI is missleading. If you print out the cMessage::getLiveMessageCount() it shows also the "correct" number of existing messages (I think the GUI gets its value from this method).

So if you decide to exclude them from counting, you should exclude it not only from the GUI because this is much more confusing or will be supposed to be a bug.

Just my humble opinion  :)

Thank you for enlighting!

Regards,

Korbinian

[Michael Kirsche]

Probably a solution without using the dup() way, how it is currently done in void LogBuffer::beginSend(cMessage *msg).
I understand the "beauty" of simply copying messages and thus enabling an exploration at some point during the simulation.
But it certainly confuses users when they rely on the message counter or operations like getLiveMessageCount().

As we shouldn't change dup(), maybe one can introduce something like a snapshot version of dup?
Without things like:

    msgid = next_id++;
    total_msgs++;
    live_msgs++;

where real shadow copies of messages are created and saved.

What do you think Andras??

[Varga, András]

You are absolutely right, the message counters shouldn't reflect these internal message copies. And yes, the GUI is simply displaying cMessage::getLiveMessageCount() on the toolbar.

Fix is in the bug tracker as an attached patch file: http://dev.omnetpp.org/bugs/view.php?id=796

Cheers
Andras

[Michael Kirsche]

Hi Andras,

hmm the patch doesn't seem to work correct for me.

After I apply the patch and re-compile OMNeT, I tested the TicToc example.
Step-by-step simulation and normal speed work fine, but once you start the fast mode, the number of existing messages increased negatively, which continues afterwards even with normal and step-by-step mode.

Fast mode handles things in a different way I guess...

Regards,
Michael

[Varga, András]

Hi Michael,

The destructor needs to be modified too, so that for internal copies it doesn't decrement the live message count...  You saw negative numbers when LogBuffer reached maximum history size and started to discard the stored clones of messages.

I uploaded an improved patch to the same bug report (#796).

Best,

Andras

[Michael Kirsche]

Thanks Andras, I'll check it out as soon as possible!

Best wishes,
Michael

[Michael Kirsche]

Hi Andras,

so far it looks pretty good. Did experienced any side effects this time.

I think it's working just fine now.

Best,
Michael

[vanders...@gmail.com]

Hi Andras, 

The copy does not only concern network channels, but all channels. But only the messages on network channels are displayed for debugging.

 My suggestion is to stop copying messages which are sent over non-network channels. 

Secondly, using rather large messages, omnetpp stopped probably because running out of memory. Can something be done there as well? 

Thanks peter

Op vrijdag 5 december 2014 13:16:15 UTC+1 schreef Varga, András: