OMNeT++/OMNEST Bug Tracker - OMNeT++
View Issue Details
0000384OMNeT++simulation kernelpublic2011-07-23 15:272011-07-26 11:34
dp 
rhornig 
normalminoralways
resolvedfixed 
4.1 
4.2b1 
0000384: Deep passing of parameters in NED files causes crash
For the following bug report, I attached an Omnet IDE Project containing a minimal example exhibiting this issue.

Consider a network N, a composite module C and a submodule S. S has a parameter S.p. S is a part of C, but C does not define S.p. If S.p is defined in the ini file, all is well. If N tries to set C.S.p to a fixed value, all is well. If N has a parameter N.q and tries to set C.S.p = N.p, Omnet crashes during network setup.

If the names of C.p and N.q differ (see network "net2"), omnet will throw an error:
"<!> Error in module (SubModule) PpeNetwork2.main.submodule (id=3) during network setup: Error evaluating parameter `subModuleParameter': has no parameter named `networkParameter'."

If the names of C.p and N.q are identical (see network "net1"), omnet will segfault. I once managed to step around the omnet code in the debugger. During parameter parsing the code for retrieving S.p is supposedly moving up the module hierarchy in search of the parameter p. This however seems not to work, as a call to evaluate() will repeatedly appear on the (ever growing) call stack. At some point, the program will crash with a segfault.

This should either be resolved so that deep passing of parameters in NED files does work (it is quite intuitive, since this is possible in INI files as well) or at least it should be documented (and the NED editor should show an error) that this is not allowed.
No tags attached.
zip ParamPassingExample.zip (7,069) 2011-07-23 15:27
https://dev.omnetpp.org/bugs/file_download.php?file_id=69&type=bug
Issue History
2011-07-23 15:27dpNew Issue
2011-07-23 15:27dpFile Added: ParamPassingExample.zip
2011-07-26 11:34rhornigNote Added: 0000528
2011-07-26 11:34rhornigStatusnew => resolved
2011-07-26 11:34rhornigFixed in Version => 4.2b1
2011-07-26 11:34rhornigResolutionopen => fixed
2011-07-26 11:34rhornigAssigned To => rhornig

Notes
(0000528)
rhornig   
2011-07-26 11:34   
Already fixed in the 4.2 branch