OMNeT++/OMNEST Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000028OMNeT++simulation kernelpublic2008-12-07 13:242008-12-09 17:26
Assigned Toandras 
PlatformOSOS Version
Product Version4.0b8 
Target VersionFixed in Version4.0rc1 
Summary0000028: Setting the displayString fails sometimes
DescriptionSetting the display string fails sometimes.

Example to reproduce:
Create a new Sink-Source project with the IDE new project wizard.

Add the following line at the end of Sink::initialize():


If you start the simulation the connection arrow stays black.

valgrind output:

==12553== Conditional jump or move depends on uninitialised value(s)
==12553== at 0x45857BE: (within /lib/tls/i686/cmov/
==12553== by 0x4589380: vfprintf (in /lib/tls/i686/cmov/
==12553== by 0x45AF0E3: vsnprintf (in /lib/tls/i686/cmov/
==12553== by 0x46D88FF: opp_stringf(char const*, ...) (
==12553== by 0x4394BD2: cNEDDeclaration::doConnectionProperties(int, char const*) const (
==12553== by 0x4394ED2: cNEDDeclaration::getConnectionProperties(int, char const*) const (
==12553== by 0x439A89F: cDynamicModuleType::getConnectionProperties(int, char const*) const (
==12553== by 0x42EBB3D: cChannel::getProperties() const (
==12553== by 0x42EDAD8: cComponent::getDisplayString() (
==12553== by 0x430E21F: cGate::getDisplayString() (
==12553== by 0x430E232: cGate::setDisplayString(char const*) (
==12553== by 0x804BAAA: simpleproject::Sink::initialize() (
Additional InformationUbuntu 8.04
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
andras (administrator)
2008-12-08 14:04

The display string has to be set on the "source" side of the connection, i.e. it affects the connection between gate g and g->getNextGate().

When I change it to the following, it works ok (arrow becomes red):

baumgart (reporter)
2008-12-08 14:58

If I use the outgoing gate, the arrow becomes red for me too.

But the valgrind error remains:

==10438== Use of uninitialised value of size 4
==10438== at 0x459529B: (within /lib/tls/i686/cmov/
==10438== by 0x4597209: vfprintf (in /lib/tls/i686/cmov/
==10438== by 0x45BAC03: vsnprintf (in /lib/tls/i686/cmov/
==10438== by 0x46DA171: opp_stringf(char const*, ...) (
==10438== by 0x4399FDD: cNEDDeclaration::doConnectionProperties(int, char const*) const (netbuilder/
==10438== by 0x439A28F: cNEDDeclaration::getConnectionProperties(int, char const*) const (netbuilder/
==10438== by 0x439FCE7: cDynamicModuleType::getConnectionProperties(int, char const*) const (netbuilder/
==10438== by 0x42EE79D: cChannel::getProperties() const (
==10438== by 0x42F096D: cComponent::getDisplayString() (
==10438== by 0x43113E5: cGate::getDisplayString() (
==10438== by 0x43113F8: cGate::setDisplayString(char const*) (
==10438== by 0x804C72C: simpleproject::Sink::initialize() (

I'm still assuming this leads to unexpected behavior (e.g. setting the displayString "sometimes" fails)
andras (administrator)
2008-12-09 17:26

Fixed. It was relatively harmless; worst thing it could possibly cause is that a dynamically created connection picks up the display string of another connection, declared the NED file. I don't think it could cause setDisplayString() to fail. (Patch: add "connId=-1;" into cChannel ctor, sim/

Marking as resolved for now; please reopen if other channel display string problems come up.

- Issue History
Date Modified Username Field Change
2008-12-07 13:24 baumgart New Issue
2008-12-08 14:04 andras Note Added: 0000078
2008-12-08 14:58 baumgart Note Added: 0000079
2008-12-09 17:26 andras Note Added: 0000086
2008-12-09 17:26 andras Status new => resolved
2008-12-09 17:26 andras Fixed in Version => 4.0rc1
2008-12-09 17:26 andras Resolution open => fixed
2008-12-09 17:26 andras Assigned To => andras

Copyright © 2000 - 2022 MantisBT Team
Powered by Mantis Bugtracker