Bugzilla – Bug 2292
Uninitialized variables since commit 7c60a9f8f271
Last modified: 2016-02-16 17:18:48 UTC
Created attachment 2264 [details] Scratch code to trigger described bugs Commit 7c60a9f8f271 includes refactoring for MPDU aggregation (bug #2116) and Wi-Fi helpers (#2213). Looks like it introduced several bugs at once since simple Ad-Hoc scenario (attached) generates valgrind warnings and/or aborts due to uninitialized variables since this commit. First attachment is a script with 3 VHT Ad-Hoc STAs, two of which send UDP packets to third. It has boolean variable that controls packet interval. When packet interval is large enough (--crash=false) NS-3 finishes successfully with one valgrind warning only. I will attach patch in subsequent message that resolves the warning. When packet interval is too small (--crash=true) NS-3 aborts: % ./waf --run 'vhttestcase --crash=true' ... msg="Reserved configuration.", file=../src/wifi/model/ctrl-headers.cc, line=139 terminate called without an active exception Command ['.../scratch/vhttestcase'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run <program> --command-template="gdb --args %s <args>").
Created attachment 2265 [details] Patch to initialize m_htSupported and m_vhtSupported ./waf --run 'vhttestcase' --command-template='valgrind --track-origins=yes %s --crash=false' Output of the command above starts with: ==26407== Conditional jump or move depends on uninitialised value(s) ==26407== at 0x50E80CB: ns3::RegularWifiMac::SetHtSupported(bool) (regular-wifi-mac.cc:389) ==26407== by 0x50F428E: ns3::Ptr<ns3::AttributeAccessor const> ns3::DoMakeAccessorHelperTwo<ns3::BooleanValue, ns3::RegularWifiMac, bool, bool>(void (ns3::RegularWifiMac::*)(bool), bool (ns3::RegularWifiMac::*)() const)::MemberMethod::DoSet(ns3::RegularWifiMac*, ns3::BooleanValue const*) const (attribute-accessor-helper.h:451) ==26407== by 0x50F7F54: ns3::AccessorHelper<ns3::RegularWifiMac, ns3::BooleanValue>::Set(ns3::ObjectBase*, ns3::AttributeValue const&) const (attribute-accessor-helper.h:188) ==26407== by 0x76E1A38: ns3::ObjectBase::DoSet(ns3::Ptr<ns3::AttributeAccessor const>, ns3::Ptr<ns3::AttributeChecker const>, ns3::AttributeValue const&) (object-base.cc:186) ==26407== by 0x76E122A: ns3::ObjectBase::ConstructSelf(ns3::AttributeConstructionList const&) (object-base.cc:165) ==26407== by 0x76E56B6: ns3::Object::Construct(ns3::AttributeConstructionList const&) (object.cc:145) ==26407== by 0x772FE82: ns3::ObjectFactory::Create() const (object-factory.cc:103) ==26407== by 0x51D0443: ns3::Ptr<ns3::WifiMac> ns3::ObjectFactory::Create<ns3::WifiMac>() const (object-factory.h:200) ==26407== by 0x51D6E44: ns3::WifiMacHelper::Create() const (wifi-mac-helper.cc:71) ==26407== by 0x51C3A66: ns3::WifiHelper::Install(ns3::WifiPhyHelper const&, ns3::WifiMacHelper const&, ns3::NodeContainer) const (wifi-helper.cc:109) ==26407== by 0x40B2C4: main (vhttestcase.cc:76) ==26407== Uninitialised value was created by a heap allocation ==26407== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==26407== by 0x51220B1: ns3::TypeId ns3::TypeId::AddConstructor<ns3::AdhocWifiMac>()::Maker::Create() (type-id.h:596) ==26407== by 0x502A9BB: ns3::FunctorCallbackImpl<ns3::ObjectBase* (*)(), ns3::ObjectBase*, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty>::operator()() (callback.h:446) ==26407== by 0x6FBD0EE: ns3::Callback<ns3::ObjectBase*, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty>::operator()() const (callback.h:1272) ==26407== by 0x772FD6A: ns3::ObjectFactory::Create() const (object-factory.cc:99) ==26407== by 0x51D0443: ns3::Ptr<ns3::WifiMac> ns3::ObjectFactory::Create<ns3::WifiMac>() const (object-factory.h:200) ==26407== by 0x51D6E44: ns3::WifiMacHelper::Create() const (wifi-mac-helper.cc:71) ==26407== by 0x51C3A66: ns3::WifiHelper::Install(ns3::WifiPhyHelper const&, ns3::WifiMacHelper const&, ns3::NodeContainer) const (wifi-helper.cc:109) ==26407== by 0x40B2C4: main (vhttestcase.cc:76) The problem is that SetHtSupported uses variable m_vhtSupported and SetVhtSupported uses variable m_htSupported. This bug is not harmful: if both SetHtSupported and SetVhtSupported are called, the state will always be the same.
Created attachment 2266 [details] valgrind log for 'vhttestcase --crash=true' Output of ./waf --run 'vhttestcase' --command-template='valgrind --track-origins=yes %s --crash=true' &> log.log is attached. It contains 3 valgrind warnings. Maybe related to bug #2275, but the same script worked correctly with slight modifications (using Vht helper and enabling aggregation manually) before 7c60a9f8f271.
I pushed the patch to initialize variables but leave the issue open for Sebastien to check the other reported bug.
Thanks a lot for reporting, it is indeed a critical issue. Tom already approved your fix for Valgrind, and I have a fix ready for the assert that is triggered: msg="Reserved configuration.", file=../src/wifi/model/ctrl-headers.cc, line=139 terminate called without an active exception The problem was that we are now using the TID info from the BACKREQ (which was not the case before refactoring), but this was removed from the packet while performing aggregation. I will submit the fix later today. I will perform other tests in the coming two weeks before the upcoming release, to make sure we did not break anything else.
Created attachment 2267 [details] patch to fix assert issue The BAR header was not appended to the packet in case of a Block Ack Request. This fixes the problem: this now appends the BAR header to m_currentPacket.
I tested the patch, assert is fixed, but 3 valgrind errors still remain.
(In reply to Alexander Krotov from comment #6) > I tested the patch, assert is fixed, but 3 valgrind errors still remain. Ok, I had not checked valgrind, I thought it was fixed by your patch, so misunderstanding. I will have a look.
Created attachment 2269 [details] patch to fix valgrind issues This should fix remaining valgrind issues.
Just verified, with all 3 patches applied there are no assertion failures or valgrind errors. Once all patches are committed to ns-3-dev, the bug can be closed I think, thanks.
Alexander, thanks for your feedback. I will deliver those changes very soon to ns-3-dev.
Fixed in changeset 11879:25c9a0b099de