Memory issue in omnet or inetmanet-2.0

[Francisco Estevez]

Hi to everybody.

I started with a battery of test in omnet++ (omnetp 4.4.1 + inetmanet 2.0 running under Ubuntu 14.04), trying to validate some network protocol features. At this point, i have a problem with large commandline simulations (With the IDE, i don't have any problem). Everytime that i am trying to run more than 50 nodes, the simulation suddenly crashes (i don't receive any msg, just "Killed"). I think it is the operating system, who kills the simulation due to a huge memory RAM use. I was checking the memory usage and it goes up to 8GB RAM (I don't find this behaviour normal). 

I have enabled the undisposed msg feature and there are a large amount of msg there (my self-defined msg) and some timers. Could it be the problem?

If i understand right, the undisposed elements are elements with no use but that cannot be deallocated, due to a problem with the destructor (maybe?). Then the garbage collector cleans all of them when finish is invoked, not before. Is it my assumption right?

I was checking the msg file structure, but my msg is very simple, just some parameters in it. Therefore i don't know how to handle with this issue, and it would be desirable to develop large simulations.

Do you have any idea?

Thanks in advance,

Francisco Estevez

[Michael Kirsche]

Seems to be more a memory issue with your code that with OMNeT.

If you have a large number of undisposed messages, you should check and debug your code to find out where they are generated, where they are send and when they could (but apparently are not) deleted.
I can only imagine that the problem is not showing itself under the IDE because you are not running the simulation as long/far as under the command line. The number of generated (and not deleted) messages is much higher under the CMD environment compared to the IDE, correct?

Try to debug (under the IDE) your code and get rid of those undisposed objects (messages).

[Francisco Estevez]

Hi Michael, 

thanks a lot. That is exactly what i supposed.

But i have another question, is there any point where i can trace the undisposed elements?. I mean, can i find the origin of an undisposed element reading the cHeap or anything like that?

Regards,

F

[Michael Kirsche]

Dear Francisco,

Not that I know of.
I try to catch them by:
(1) changing names of similar messages to differ between them (and find out which are undisposed)
(2) trace them in the GUI, windows of undisposed objects are never closed during the simulation, that makes it easy to find out which message is not deleted where it actually should have been
(3) step through the code in the debugger to see why a message is not deleted.

If anyone knows an easier tracking / tracing function, let us know!

Best,
Michael

[Francisco Estevez]

Hi Michael,

thanks a lot. 

About your question, there is no difference in the number of nodes or time between the GUI-based or the commandline simulations, therefore i don't know the problem between them (It seems like the GUI uses a kind of container to limit the memory usage or something like that).

About your tips, i debugged but i can not find anything strange. Where can i find the windows of undisposed objects in the GUI?

Regards,

F

[Alfonso Ariza Quintana]

If the problem is due to undeleted messages, it is complex to detect with the debug and valgrind because the messages aren’t marked like lost memory. You need to change the code and delete the messages after receive it.

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de Francisco Estevez
Enviado el: miércoles, 22 de julio de 2015 9:55
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: [Omnetpp-l] Re: Memory issue in omnet or inetmanet-2.0

 

Hi Michael,

 

thanks a lot. 

About your question, there is no difference between the number of nodes or time between the GUI-based or the commandline simulations, therefore i don't know the problem between them (It seems like the GUI uses a kind of container to limit the memory usage or something like that).

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

[Francisco Estevez]

Hi Alfonso,

well, that could be possible, but i need to process the msg and take decision based on the kind of msg and the content of the payload. I checked the function that receives from mac and the received msg should be always deleted.

One point is that i am deleting the msg after than a new msg sending, maybe that is the issue, referring on how omnet++ schedules (I mean, i am putting more msgs in the queue than deleting them and perhaps omnetpp frees memory slower).

Regards,

F

--
You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/R5gnTvcPjgY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.

[Alfonso Ariza Quintana]

I have suffered problems with the memory in Windows, sometimes even if you delete the object, the memory manager does not reuse the free memory, sometimes the same simulation consume a lot of memory and when you repeat the simulation, with the same parameters, runs smoothly, but have not had the same problem in Linux.

[Francisco Estevez]

It is very interesting, because if i use valgrind or the GUI, i don't have the memory issues, otherwise if i am using the commandline, it breaks due to memory usage.

Checking the undisposed list showed at the end, some packets show their name, but the others just show "--", therefore i have no idea where the trouble is. I am debugging and the simulation reachs the destructor of the msg class without problems and it runs smoothly.

Regards,

F

[Michael Kirsche]

If the program crashed without GDB but runs normal with GDB, I'd suggest to set the necessary environment variable to create core dumps (for crashed programs) and then investigate the dump with GDB afterwards.
Maybe it is some uninitialized pointer or variable that is redefined/treated differently under GDB.

[Michael Kirsche]

http://bloggerdigest.blogspot.de/2006/09/gnu-gdb-core-dump-debugging.html

[Francisco Estevez]

Well Michael, not really, it crashed debugging or without debugging, but just under the commandline. With GUI works great in both ways.

I reviewed the destructor of my MSG class (there is where i have my problem) and they are reached without problems, but it seems like the instance of the class is empty because there is no name for the undisposed objects. I was thinking in a problem with the destructor of a class similar to IPv4Address (i implemented my own address class) and maybe that was resulting in a problem freeing the memory, but i don't know how to  check it. 

If i used the debugger, how can i know if the memory is being freed (if i checked the memory address of the variable, i can checked it, but is it any other method?).

Regards,

F 

[Michael Kirsche]

You could make gdb print out a note whenever your free command is called: https://stackoverflow.com/questions/12757550/how-to-get-notified-in-gdb-when-memory-is-freed
Never tried it though.
I usually take the road of checking where my objects should have been deleted and then find out why they aren't deleted.
Having undisposed objects without a name never happened to me yet.

[Francisco Estevez]

Thank you Michael,

I guess that i'm having a problem with not used objects. I mean, i create somewhere an empty object, but it is never filled, and then trying to destroy it, that is the reason to have any name in (at least that is what i think).

I have solved some issues, and now less memory is used, but anyway, i still can not develop large simulations.  

Regards,

Fran

[Michael Kirsche]

Any simple example simulation where one can trace your steps and simulation scenarios?

[Danh Le Dinh]

Hi Francisco,
Did you solve your memory-related problem with large simulations? I am facing the same problem. It is even worse that the simulation crashes at 12% of RAM (~3GB). My simulation uses INET TCP/IP models and traffic is fed by tcpApps. As I understand, traffic sent from tcpApps to tcp module will be queued in TCP's SendQueue, and this queue is set as infinite queue. If the network cannot transmit the necessary amount to the destinations in time, then the traffic accumulated at SendQueue will exceed the permitted RAM, and the simulation crashes. What I don't understand for sure is the RAM still has a lot, but the simulation crashes at 12% of it. I hope you solved your problem, if so please share it please.

If anyone has experienced similar problem, or has some idea for it, I'm all ears!

Thanks a lot.

Danh