OMNeT++/OMNEST Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
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
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
Attached Files

- Relationships
has duplicate 0000257resolvedrhornig opp_run: no user interface available 

-  Notes
(0000387)
rhornig (administrator)
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 (administrator)
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.

- Issue History
Date Modified Username Field Change
2010-07-26 11:27 rhornig New Issue
2011-02-09 17:05 rhornig Note Added: 0000387
2011-05-20 10:02 rhornig Relationship added has duplicate 0000257
2012-01-09 17:40 rhornig Note Added: 0000669
2012-01-09 17:40 rhornig Status new => resolved
2012-01-09 17:40 rhornig Fixed in Version => 4.2
2012-01-09 17:40 rhornig Resolution open => fixed
2012-01-09 17:40 rhornig Assigned To => rhornig
2016-06-06 08:47 kibrom Tag Attached: solution


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker