Bugzilla – Bug 1570
valgrind errors in new test examples
Last modified: 2013-01-21 11:29:58 UTC
The new examples added due to bug 1563 picked up some new valgrind errors, which need to be corrected (they seem to me like they may be valid). To reproduce (also seen here in this buildslave): https://ns-buildmaster.ee.washington.edu:8010/job/Daily-with-valgrind/label=Fedora-64-15/181/consoleText $ ./waf --valgrind --run "lena-simple-epc --simTime=1.1 --ns3::LteHelper::Scheduler=ns3::PssFfMacScheduler" Waf: Entering directory `/home/watrous/repositories/ns-3-allinone/ns-3-dev/build' Waf: Leaving directory `/home/watrous/repositories/ns-3-allinone/ns-3-dev/build' 'build' finished successfully (3.554s) ==12205== Memcheck, a memory error detector ==12205== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==12205== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==12205== Command: /home/watrous/repositories/ns-3-allinone/ns-3-dev/build/src/lte/examples/ns3-dev-lena-simple-epc-debug --simTime=1.1 --ns3::LteHelper::Scheduler=ns3::PssFfMacScheduler ==12205== ==12205== Conditional jump or move depends on uninitialised value(s) ==12205== at 0x51A5423: ns3::PssFfMacScheduler::DoCschedLcConfigReq(ns3::FfMacCschedSapProvider::CschedLcConfigReqParameters const&) (pss-ff-mac-scheduler.cc:330) $ ./waf --valgrind --run "lena-simple-epc --simTime=1.1 --ns3::LteHelper::Scheduler=ns3::FdTbfqFfMacScheduler" Waf: Entering directory `/home/watrous/repositories/ns-3-allinone/ns-3-dev/build' Waf: Leaving directory `/home/watrous/repositories/ns-3-allinone/ns-3-dev/build' 'build' finished successfully (3.564s) ==12209== Memcheck, a memory error detector ==12209== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==12209== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==12209== Command: /home/watrous/repositories/ns-3-allinone/ns-3-dev/build/src/lte/examples/ns3-dev-lena-simple-epc-debug --simTime=1.1 --ns3::LteHelper::Scheduler=ns3::FdTbfqFfMacScheduler ==12209== ==12209== Conditional jump or move depends on uninitialised value(s) ==12209== at 0x518FB5E: ns3::FdTbfqFfMacScheduler::DoSchedDlTriggerReq(ns3::FfMacSchedSapProvider::SchedDlTriggerReqParameters const&) (fdtbfq-ff-mac-scheduler.cc:482) $ ./waf --valgrind --run "lena-simple-epc --simTime=1.1 --ns3::LteHelper::Scheduler=ns3::TdTbfqFfMacScheduler" Waf: Entering directory `/home/watrous/repositories/ns-3-allinone/ns-3-dev/build' Waf: Leaving directory `/home/watrous/repositories/ns-3-allinone/ns-3-dev/build' 'build' finished successfully (3.506s) ==16111== Memcheck, a memory error detector ==16111== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==16111== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==16111== Command: /home/watrous/repositories/ns-3-allinone/ns-3-dev/build/src/lte/examples/ns3-dev-lena-simple-epc-debug --simTime=1.1 --ns3::LteHelper::Scheduler=ns3::TdTbfqFfMacScheduler ==16111== ==16111== Conditional jump or move depends on uninitialised value(s) ==16111== at 0x519C110: ns3::TdTbfqFfMacScheduler::DoSchedDlTriggerReq(ns3::FfMacSchedSapProvider::SchedDlTriggerReqParameters const&) (tdtbfq-ff-mac-scheduler.cc:480)
The issue traces back to the EpsBearer class, which is normally used for configuration within the main program. So the problem is outside Dizhi's schedulers. It didn't show up before, because no scheduler before Dizhi's work used those variables. I've just pushed to ns-3-dev the following changes that fix the problem (the first one is backported from one of the LENA development branches): changeset: 9223:0037859c17c9 user: Nicola Baldo <nbaldo@cttc.es> date: Wed Dec 19 17:34:54 2012 +0100 summary: initialize member variables of EpsBearer upon construction changeset: 9224:16af460a31ab tag: tip user: Nicola Baldo <nbaldo@cttc.es> date: Mon Jan 21 17:10:14 2013 +0100 summary: fixed typo in eps-bearer.h