#5 usePropagationDelay memory leak

closed-fixed
nobody
None
8
2010-07-07
2010-07-06
Galactix
No

In my own modification of the Mac80211 example using the simplePathlossModel I get memory leaks whenever setting usePropagationDelay to true in omnetpp.ini.

This is not a problem in a case with 10 nodes, but I want to simulate up to 400. Using a debugger we found out the problem is in BasePhyLayer.cc:349 "Signal& s = frame->getSignal();" but since this is not my code (and have no time to completely comprehend what happens here) I figured I'd post it as a bug.

I am using version 1.1 and made no modifications to the PHY.

Discussion

  • Galactix

    Galactix - 2010-07-06
    • priority: 5 --> 8
     
  • Galactix

    Galactix - 2010-07-06

    After running it a bit more in valgrind, I find out BasePhyLayer is probably not to blame:

    ==13593== 21,315,552 (754,240 direct, 20,561,312 indirect) bytes in 18,856 blocks are definitely lost in loss record 152 of 152
    ==13593== at 0x4C28CC1: operator new(unsigned long) (vg_replace_malloc.c:261)
    ==13593== by 0x4EFA3B2: __gnu_cxx::new_allocator<std::_Rb_tree_node<Dimension> >::allocate(unsigned long, void const*) (new_allocator.h:89)
    ==13593== by 0x4EFA28B: std::_Rb_tree<Dimension, Dimension, std::_Identity<Dimension>, std::less<Dimension>, std::allocator<Dimension> >::_M_get_node() (stl_tree.h:359)
    ==13593== by 0x4EF9F74: std::_Rb_tree<Dimension, Dimension, std::_Identity<Dimension>, std::less<Dimension>, std::allocator<Dimension> >::_M_create_node(Dimension const&) (stl_tree.h:369)
    ==13593== by 0x4F0F604: std::_Rb_tree<Dimension, Dimension, std::_Identity<Dimension>, std::less<Dimension>, std::allocator<Dimension> >::_M_insert_(std::_Rb_tree_node_base const*, std::_Rb_tree_node_base const*, Dimension const&) (stl_tree.h:881)
    ==13593== by 0x4F0E8C3: std::_Rb_tree<Dimension, Dimension, std::_Identity<Dimension>, std::less<Dimension>, std::allocator<Dimension> >::_M_insert_unique(Dimension const&) (stl_tree.h:1177)
    ==13593== by 0x4F0DF84: std::set<Dimension, std::less<Dimension>, std::allocator<Dimension> >::insert(Dimension const&) (stl_set.h:411)
    ==13593== by 0x4F0D74D: DimensionSet::DimensionSet(Dimension const&) (MappingBase.h:177)
    ==13593== by 0x4F11337: ConstMapping::ConstMapping() (MappingBase.h:619)
    ==13593== by 0x4F149F5: Mapping::Mapping() (MappingBase.h:863)
    ==13593== by 0x4F14DDA: LinearIntplMapping::LinearIntplMapping(ConstMapping*, ConstMapping*, double) (MappingUtils.h:495)
    ==13593== by 0x4F15220: Interpolated<Mapping*>::Interpolated(Mapping*, bool) (MappingUtils.h:593)

    This suggests something is happening in the MappingUtils / Mappings. I already had some trouble here when using radio switching times. I'll post more if I find out more details.

     
  • Galactix

    Galactix - 2010-07-06

    The CSMAmac example has the same problem, though the examples terminate before getting into memory problems. Here too valgrind says there is a problem, though I am not very good at reading valgrind's output:

    ==14234== 549,928 (534,664 direct, 15,264 indirect) bytes in 1,261 blocks are definitely lost in loss record 105 of 105
    ==14234== at 0x4C28CC1: operator new(unsigned long) (vg_replace_malloc.c:261)
    ==14234== by 0x4F1FA79: TimeMapping<Linear>::createIterator() (MappingUtils.h:342)
    ==14234== by 0x4F14B2C: Mapping::createConstIterator() (MappingBase.h:913)
    ==14234== by 0x4EFA663: BaseDelayedMapping<ConstMapping>::createConstIterator() (MappingUtils.h:2164)
    ==14234== by 0x4EFADC5: Mapping* MappingUtils::applyElementWiseOperator<std::multiplies<double> >(ConstMapping&, ConstMapping&, std::multiplies<double>, double, bool) (MappingUtils.h:1807)
    ==14234== by 0x4EFAA2A: ConcatConstMapping<std::multiplies<double> >::createConcatenatedMapping() (MappingUtils.h:2015)
    ==14234== by 0x4EFA404: ConcatConstMapping<std::multiplies<double> >::createConstIterator() (MappingUtils.h:2027)
    ==14234== by 0x4F18E56: Mapping* MappingUtils::applyElementWiseOperator<std::divides<double> >(ConstMapping&, ConstMapping&, std::divides<double>, double, bool) (MappingUtils.h:1807)
    ==14234== by 0x4F13528: MappingUtils::divide(ConstMapping&, ConstMapping&, double) (MappingUtils.cc:187)
    ==14234== by 0x4EF7408: BaseDecider::calculateSnrMapping(AirFrame*) (BaseDecider.cc:213)
    ==14234== by 0x520DB29: SNRThresholdDecider::processSignalEnd(AirFrame*) (SNRThresholdDecider.cc:58)
    ==14234== by 0x4EF65CB: BaseDecider::processSignal(AirFrame*) (BaseDecider.cc:21)

     
  • Karl Wessel

    Karl Wessel - 2010-07-07

    I think we fixed that bug a while a go in the repository but since we hadn't any release for a while now it wasn't really made public yet.
    If you want you can check if the problem still occurs with the latest version from the git repository. Or you can just wait for the release of MiXiM 1.2 which will come during this or the next week.

     
  • Galactix

    Galactix - 2010-07-07

    Had a look at the latest versions of MappingUtils.h and .cc in the git, these fix the problem. Thanks!

     
  • Galactix

    Galactix - 2010-07-07
    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks