OMNeT++/OMNEST Bug Tracker - OMNeT++
View Issue Details
0000570OMNeT++simulation kernelpublic2012-05-16 16:312012-05-16 16:39
andras 
 
normalminoralways
newopen 
4.2.2 
 
0000570: NaN-valued module parameter causes further similar parameters to be NaN as well
If a module parameter of type double is assigned NaN, e.g. as 0/0, further parameters of the same name, type, unit etc. will be incorrectly set to NaN as well.

E.g. if a parameter of a module in a module vector is set to NaN, further elements in the module vector will have that parameter to be set to NaN as well.

No tags attached.
Issue History
2012-05-16 16:31andrasNew Issue
2012-05-16 16:39andrasNote Added: 0000755

Notes
(0000755)
andras   
2012-05-16 16:39   
Cause:

cPar::convertToConst() tries to replace the paramImpl with a cached copy:
    cParImpl *cachedValue = componentType->getSharedParImpl(p);
    if (cachedValue)
        setImpl(cachedValue);
    else
        componentType->putSharedParImpl(p);

Here, componentType->getSharedParImpl(p) can (incorrectly) return a NaN-valued but otherwise matching paramImpl object, regardless of what double value is in "p".

getSharedParImpl() uses an underlying std::set, a binary tree which relies on a "less" operator for finding an element. This std::set incorrectly finds the NaN paramImpl.

The cause is cDoubleParImpl::compare(const cParImpl *other) that contains this line:
        return (val == other2->val) ? 0 : (val < other2->val) ? -1 : 1;

Problem is that both x<NaN and x>NaN are false, which confuses the std::set.


Solution proposal: modify cDoubleParImpl::compare() so that NaN always compares as greater (or less) to all real numbers, including +-inf.