OMNeT++/OMNEST Bug Tracker - OMNeT++
View Issue Details
0000257OMNeT++command line toolspublic2011-02-23 11:452011-05-20 10:02
0000257: opp_run: no user interface available
From time to time, the opp_run command line tool stops executing with the following statement:

User interface 'Cmdenv' not found (not linked in or loaded dynamically).
Available ones are:

<!> Error during startup: Could not start user interface 'Cmdenv'.


I always work with mixim, and there could be some problem between the mixim libraries and the omnet libraries.
If I rebuild mixim in release mode, then my simulation runs (and crashes at some point in the code, which is why I want to debug it). Either with the tcl/tk or cmdenv interface.
I tried again with gdb from eclipse, activating "verbose console mode" in the Debug configuration.
I obtain the following information:

71-stack-list-frames 0 1
73 info signal SIGSEGV
74 info signal SIGSEGV
71^done,stack=[frame={level="0",addr="0x00007ffff716cba0",func="cObject::getFullPath() const",from="/home/jerome/software/omnest-4.1/lib/"},frame={level="1",addr="0x00007ffff716cbfe",func="cObject::getFullPath() const",from="/home/jerome/software/omnest-4.1/lib/"}]
&"info signal SIGSEGV\n"
info signal SIGSEGV
~"Signal Stop\tPrint\tPass to program\tDescription\n"
Signal Stop Print Pass to program Description
~"SIGSEGV Yes\tYes\tYes\t\tSegmentation fault\n"
SIGSEGV Yes Yes Yes Segmentation fault

So it seems that oppsim segfaults while calling
cObject::getFullPath() const () from /home/jerome/software/omnest-4.1/lib/\n"

Just before that, gdb verbose mode gives me the list of currently shared libraries. It ends with library, probably the last loaded library:
67 info sharedlibrary
&"info sharedlibrary\n"
~"From To Syms Read Shared Object Library\n"
~"0x00007ffff7dddaf0 0x00007ffff7df66c4 Yes /lib64/\n"
~"0x00007ffff7b31e60 0x00007ffff7b56698 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff78b10d0 0x00007ffff78f6558 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff7666f60 0x00007ffff767a338 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff7453ac0 0x00007ffff7457ea8 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff712bd80 0x00007ffff71eae68 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff6e02440 0x00007ffff6e5c0f8 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff6b9b580 0x00007ffff6bb3468 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff686dc50 0x00007ffff694c0f8 Yes /usr/lib/\n"
~"0x00007ffff663bde0 0x00007ffff663c9c8 Yes /lib/\n"
~"0x00007ffff63814a0 0x00007ffff63f8236 Yes /usr/lib/\n"
~"0x00007ffff60a7ef0 0x00007ffff60e87f8 Yes /lib/\n"
~"0x00007ffff5e8fd80 0x00007ffff5ea03c8 Yes /lib/\n"
~"0x00007ffff5b288c0 0x00007ffff5c3b5e0 Yes /lib/\n"
~"0x00007ffff57fcb70 0x00007ffff58c9048 Yes /usr/lib/\n"
~"0x00007ffff54d6d70 0x00007ffff5597c38 Yes /usr/lib/\n"
~"0x00007ffff52a2260 0x00007ffff52aed38 Yes /lib/\n"
~"0x00007ffff50883e0 0x00007ffff5094388 Yes /lib/\n"
~"0x00007ffff4d67f40 0x00007ffff4df5d18 Yes /usr/lib/\n"
~"0x00007ffff4b49d00 0x00007ffff4b4ad18 Yes /usr/lib/\n"
~"0x00007ffff493a8b0 0x00007ffff49459e8 Yes /usr/lib/\n"
~"0x00007ffff47262a0 0x00007ffff4733328 Yes /usr/lib/\n"
~"0x00007ffff44a77d0 0x00007ffff44ff808 Yes /usr/lib/\n"
~"0x00007ffff426d5c0 0x00007ffff4287738 Yes /usr/lib/\n"
~"0x00007ffff405ead0 0x00007ffff4065148 Yes /usr/lib/\n"
~"0x00007ffff3e4a090 0x00007ffff3e55558 Yes /usr/lib/\n"
~"0x00007ffff3c1bc60 0x00007ffff3c34ca8 Yes /lib/\n"
~"0x00007ffff3a14ee0 0x00007ffff3a15c78 Yes /usr/lib/\n"
~"0x00007ffff380f270 0x00007ffff3810c98 Yes /usr/lib/\n"
~"0x00007ffff35e0e90 0x00007ffff35fbb18 Yes /home/jerome/code/mixim/tests/testUtils//\n"
~"0x00007ffff3325620 0x00007ffff3386718 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff2f26080 0x00007ffff301e8a8 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff2b78860 0x00007ffff2bee1f8 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff28e54b0 0x00007ffff2906328 Yes /home/jerome/software/omnest-4.1/lib/\n"
~"0x00007ffff25f9b50 0x00007ffff267d138 Yes /home/jerome/code/mixim/base//\n"
~"0x00007ffff233c150 0x00007ffff233eb78 Yes /home/jerome/code/mixim/tests/power/utils//\n"
~"0x00007ffff1fdf440 0x00007ffff20b1b28 Yes /home/jerome/code/mixim/tests/power/utils/../../../out/gcc-debug/modules/\n"

I am running out of ideas on how to fix this problem.

No tags attached.
duplicate of 0000191resolved rhornig Switching a shared library based model to release mode from debug prevents the running of model 
Issue History
2011-02-23 11:45jeromerousselotNew Issue
2011-02-23 11:53jeromerousselotNote Added: 0000396
2011-02-23 12:05jeromerousselotNote Added: 0000397
2011-02-23 12:22rhornigNote Added: 0000398
2011-02-23 12:25rhornigNote Edited: 0000398
2011-02-23 12:28andrasNote Added: 0000399
2011-02-23 12:29andrasNote Deleted: 0000399
2011-02-23 12:30andrasNote Added: 0000400
2011-05-20 10:02rhornigRelationship addedduplicate of 0000191
2011-05-20 10:02rhornigDuplicate ID0 => 191
2011-05-20 10:02rhornigStatusnew => resolved
2011-05-20 10:02rhornigResolutionopen => duplicate
2011-05-20 10:02rhornigAssigned To => rhornig

2011-02-23 11:53   
Currently this bug is not happening "from time to time", but always.
What I meant is that it is not the first time I encounter it. In the previous cases I always had the possibility to build an executable for my simulation. In that case the problem disappeared: I could debug my simulation successfully.
With the newer versions of mixim there is a clean separation between mixim itself and user simulations using mixim, and it is less straightforward to build an executable.
2011-02-23 12:05   
I discovered that omnest actually automatically builds an executable in the simulation project. I can now debug the simulation. However If I try the opp_run executable the problem remains.
At least there is a workaround.
2011-02-23 12:22   
(edited on: 2011-02-23 12:25)
The reason for the crash is clear: if you check the loaded shared lib list, both the release and the debug version of the omnet libraries are pulled in (i.e. and This will of course cause crashes as both libs have the same global symbols for registration lists etc.

We are aware of the problem and partially fixed it in 4.2b1. The reason why the problem surfaces is that when you build the OMNET libraries (for both release and debug mode, only a single version (debug) of opp_run is created. (this opp_run version links directly with debug omnet libraries). On the other hand once you relink your own model with release libs and try to load it with opp_run, the model loads the release versions of omnet while opp_run loads the debug versions... And the "fun" begins...

Please see bug 0000191

4.2b1 will detect the double loading and will issue an error.

for a later version we will not link with omnet libs directly in opp_run.It will pull the correct version of libs dynamically using dlopen.

As a workaround: when you want to run the simulation in release mode using opp_run, be sure to delete opp_run and recreate it in release mode (make MODE=release). (of course you have to make a debug version if you switch back to debug). (or create both debug and release version compiled, rename them and make a symlink to either the relase or debug version according to your needs.

2011-02-23 12:30   
OK, Rudi's got the point.

Just make a mental note of the "CDE" (Code+Data+Environment) tool,, [^] which can be useful in the future for tracking down this kind of problems.