Query regarding crash while running LENA

[Vikram Chandrasekhar]

Hi NS3-Experts,

I experienced a crash while running LENA. The crash appears to occur within lte-stats-calculator.cc after a UL trace is fired. The error appears to be a missing entry in a lookup, [msg="Lookup /NodeList/2/DeviceList/0/LteEnbRrc/UeMap/0 got no matches", file=../src/lte/helper/lte-stats-calculator.cc, line=156].

Specifically, the crash is triggered after encountering an NS_FATAL_ERROR inside the function ns3::LteStatsCalculator::FindImsiFromEnbRlcPath, which in turn, appears to be called after a trace is fired off inside LteEnbMac::DoSchedUlConfigInd (FfMacSchedSapUser::SchedUlConfigIndParameters ind).

Has anyone experienced a similar issue?  FYI, the simulation I was running consisted of 3 macro cell eNB, 3 low power eNB and a total of 60 UE.

Error logs and gdb backtrace information given below.

thank you,

Vikram

The error message is as follows :-

msg="Lookup /NodeList/2/DeviceList/0/LteEnbRrc/UeMap/0 got no matches", file=../src/lte/helper/lte-stats-calculator.cc, line=156

libc++abi.dylib: terminate called without an active exception

Command ['/Users/vikramch/Documents/Simulation/ns3.18/ns-allinone-3.18/ns-3.18/build/scratch/cisco_MacroLpn_epc'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run <program> --command-template="gdb --args %s <args>").

Using GDB backtrace, I found the following:-

(gdb) backtrace

#0  0x00007fff8554ed46 in __kill ()

#1  0x00007fff8f4c6f83 in abort ()

#2  0x00007fff8eef89eb in abort_message ()

#3  0x00007fff8eef63a8 in default_terminate ()

#4  0x00007fff8e0db527 in std::terminate ()

#5  0x00000001004dcefd in ns3::LteStatsCalculator::FindImsiFromEnbRlcPath (path=@0x7fff5fbf5488) at lte-stats-calculator.cc:156

#6  0x00000001004dfbc2 in ns3::LteStatsCalculator::FindImsiFromEnbMac (path=@0x7fff5fbf58d8, rnti=0) at lte-stats-calculator.cc:239

#7  0x0000000100544dbe in ns3::MacStatsCalculator::UlSchedulingCallback (macStats=@0x7fff5fbf5a68, path=@0x7fff5fbf5a60, frameNo=6, subframeNo=6, rnti=0, mcs=0 '\0', size=0) at mac-stats-calculator.cc:223

#8  0x00000001004c72c2 in ns3::BoundFunctorCallbackImpl<void (*)(ns3::Ptr<ns3::MacStatsCalculator>, std::string, unsigned int, unsigned int, unsigned short, unsigned char, unsigned short), void, ns3::Ptr<ns3::MacStatsCalculator>, std::string, unsigned int, unsigned int, unsigned short, unsigned char, unsigned short, ns3::empty, ns3::empty>::operator() (this=0x105df9d00, a1=@0x7fff5fbf5b10, a2=6, a3=6, a4=0, a5=0 '\0', a6=0) at callback.h:551

#9  0x00000001006156ea in ns3::Callback<void, std::string, unsigned int, unsigned int, unsigned short, unsigned char, unsigned short, ns3::empty, ns3::empty, ns3::empty>::operator() (this=0x105e00700, a1=@0x7fff5fbf5bb0, a2=6, a3=6, a4=0, a5=0 '\0', a6=0) at callback.h:1085

#10 0x0000000100615829 in ns3::BoundFunctorCallbackImpl<ns3::Callback<void, std::string, unsigned int, unsigned int, unsigned short, unsigned char, unsigned short, ns3::empty, ns3::empty, ns3::empty>, void, std::string, unsigned int, unsigned int, unsigned short, unsigned char, unsigned short, ns3::empty, ns3::empty, ns3::empty>::operator() (this=0x105e006f0, a1=6, a2=6, a3=0, a4=0 '\0', a5=0) at callback.h:539

#11 0x000000010060e68f in ns3::Callback<void, unsigned int, unsigned int, unsigned short, unsigned char, unsigned short, ns3::empty, ns3::empty, ns3::empty, ns3::empty>::operator() (this=0x105e00720, a1=6, a2=6, a3=0, a4=0 '\0', a5=0) at callback.h:1073

#12 0x000000010060e741 in ns3::TracedCallback<unsigned int, unsigned int, unsigned short, unsigned char, unsigned short, ns3::empty, ns3::empty, ns3::empty>::operator() (this=0x105c993d0, a1=6, a2=6, a3=0, a4=0 '\0', a5=0) at traced-callback.h:240

#13 0x00000001005f8b0d in ns3::LteEnbMac::DoSchedUlConfigInd (this=0x105c992a0, ind=@0x7fff5fbf5f28) at lte-enb-mac.cc:1127

#14 0x00000001005f2fa3 in ns3::EnbMacMemberFfMacSchedSapUser::SchedUlConfigInd (this=0x105c664c0, params=@0x7fff5fbf7368) at lte-enb-mac.cc:183

#15 0x000000010095ddcd in ns3::UbiFfMacScheduler::DoSchedUlTriggerReqProportionalBufferSizePerLCG (this=0x10600ec00, params=@0x7fff5fbf8800) at ubi-ff-mac-scheduler.cc:6723

#16 0x0000000100967868 in ns3::UbiFfMacScheduler::DoSchedUlTriggerReq (this=0x10600ec00, params=@0x7fff5fbf8800) at ubi-ff-mac-scheduler.cc:2404

#17 0x000000010093279d in ns3::UbiSchedulerMemberSchedSapProvider::SchedUlTriggerReq (this=0x105c60c00, params=@0x7fff5fbf8800) at ubi-ff-mac-scheduler.cc:566

#18 0x0000000100603a29 in ns3::LteEnbMac::DoSubframeIndication (this=0x105c992a0, frameNo=6, subframeNo=6) at lte-enb-mac.cc:610

#19 0x00000001005f3714 in ns3::EnbMacMemberLteEnbPhySapUser::SubframeIndication (this=0x105c654b0, frameNo=6, subframeNo=6) at lte-enb-mac.cc:290

#20 0x0000000100277c9a in ns3::LteEnbPhy::StartSubFrame (this=0x105c98c40) at lte-enb-phy.cc:864

#21 0x000000010026a584 in ns3::EventImpl* ns3::MakeEvent<void (ns3::LteEnbPhy::*)(), ns3::LteEnbPhy*>(void (ns3::LteEnbPhy::*)(), ns3::LteEnbPhy*)::EventMemberImpl0::Notify () at make-event.h:94

#22 0x000000010518a21f in ns3::EventImpl::Invoke (this=0x10718a020) at event-impl.cc:45

#23 0x0000000105192a3d in ns3::DefaultSimulatorImpl::ProcessOneEvent (this=0x105c42a90) at default-simulator-impl.cc:140

#24 0x0000000105192d09 in ns3::DefaultSimulatorImpl::Run (this=0x105c42a90) at default-simulator-impl.cc:193

#25 0x000000010518d771 in ns3::Simulator::Run () at simulator.cc:161

#26 0x00000001000195e7 in main (argc=1, argv=0x7fff5fbff818) at cisco_MacroLpn_epc.cc:730

[Ibrahim Kiremitci]

Hey Vikram,

I also met with such a problem and did detailed debugging through log-traces. I enabled LteEnbRrc Log component and just realized the error occurs when a HandoverJoininTimeout or HandoverLeavingTimeout occurs. For instance if the UE with specific RNTI is removed through those handover timeout events, then after calling the FindImsiFromEnbRlcPath function for that specific RNTI in that cell, then the ue cannot be found. So, I guess when removing the UE with those timeout funcitons, some phsical spectrum context related to that UE still remains (maybe a previously scheduled receive event is fired).

ibrahim

[Tommaso Pecorella]

Hi both,

if you believe you found a bug, please contact the LENA maintainers. If you happen to have also a script demonstrating the bug, it would be even better.

Best regards,

T.

[Nicola Baldo]

HI Ibrahim,

actually both LteEnbRrc::HandoverJoiningTimeout () and LteEnbRrc::HandoverLeavingTimeout () cause the following methods to be called:
LteEnbRrc::RemoveUe ()
LteEnbMac::DoRemoveUe ()
XXXFfMacScheduler::DoCschedUeReleaseReq ()

so, because of the latter, I would expect that the RNTI being removed is involved in subsequent execution of XxxFfMacScheduler::DoSchedUlConfigInd ()

[Ibrahim Kiremitci]

Hi Nicola,

I am not 100% sure why it happens but when I debug it, it seems it occurs when the FindImsiFromEnbRlcPath function is called by a Rx function in uplink of the cell if the RNTI is not found, and in the log files, I am just witnessing that specific RNTI is just removed through HandoverJoiningTimeout or HandoverLeavingTimeout functions, it is why I just proposed such an idea but as I say I am not 100 % sure.

ibrahim

[Nicola Baldo]

Hi Ibrahim,

can you provide a simulation program that triggers the bug on the latest ns-3 version?
If you could file a new bug report on bugzilla and attach the program it would be great!
https://www.nsnam.org/bugzilla/