OMNeT++/OMNEST Bug Tracker - OMNeT++
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000191OMNeT++command line toolspublic2010-07-26 11:272016-06-06 08:47
Reporterrhornig 
Assigned Torhornig 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version4.1 
Target VersionFixed in Version4.2 
Summary0000191: Switching a shared library based model to release mode from debug prevents the running of model
DescriptionSteps to reproduce:
- rebuild OMNET (both release and debug libraries)
$ make cleanall
$ make

- we will use the queueinglib example as it is build as a shared library
$ cd samples/queueinglib
$ make clean
$ make MODE=release
$ cd ../queuenet
$ ./queuenet

On Windows machines with MINGW, this will start the simulation, but the simulator will not find registered simple modules and other registered classes.

You will get: "Error in module (cCompoundModule) NETWORK (id=1) during network setup: Class "XXX" not found -- perhaps its code was not linked in, or the class wasn't registered with Register_Class(), or in the case of modules and channels, with Define_Module()/Define_Channel()."

On linux this produces a segmentation fault
Steps To Reproduce
Additional InformationThe reason:

When we build the simulation for both debug and release, the opp_run command will link with the debug version of the shared libraries. If we switch the mode for a shared lib project to "release" and compile it, the resulting shared library will be linked against the release version of the omnet libraries.

Once we start this shared object via the "opp_run" command, opp_run will load the debug versions of the libs while the model will load the release versions. The two shared libs cannot see each other's registration lists etc. In general OMNET was not designed to work this way.

Similar problems will occur if a project is in debug mode and uses an other library which is release mode. Each shared lib will see different omnet library instances...

Workaround: When switching modes (especially with projects that are using other models as shared libraries or are themselves shared libraries) delete the opp_run executable and recompile the OMNET in the new mode too. Rebuilding all the used models are required too.
Tagssolution
Relationships
has duplicate 0000257resolved rhornig opp_run: no user interface available 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-07-26 11:27rhornigNew Issue
2011-02-09 17:05rhornigNote Added: 0000387
2011-05-20 10:02rhornigRelationship addedhas duplicate 0000257
2012-01-09 17:40rhornigNote Added: 0000669
2012-01-09 17:40rhornigStatusnew => resolved
2012-01-09 17:40rhornigFixed in Version => 4.2
2012-01-09 17:40rhornigResolutionopen => fixed
2012-01-09 17:40rhornigAssigned To => rhornig
2016-06-06 08:47kibromTag Attached: solution

Notes
(0000387)
rhornig   
2011-02-09 17:05   
topic/no_multiple_oppsim contains several patches to fix this.

- First the above condition must be detected and a decent error message must be shown.

Suggestion: rewrite opp_run to not link with any library directly. It must first detect if a library to load is specified. if yes, load that dynamically which will load the necessary simulation libs. The evnir lib should contain a special function similar to dllMain which should be invoked directly by opp_run.

If no shared lib model is specified, then either release or debug (whichever presen) version of envir lib must be loaded directly and invoked (along with passing the command line).
(0000669)
rhornig   
2012-01-09 17:40   
A new opp_run and opp_run_release is implemented. opp_run is always debug and detects if the loaded libs are in release mode. If yes, it starts them with opp_run_release.