Cisco CM services restart spontaneously

[Marian Dolinsky]

Hi All,

Please can anyone advise what can be the cause the Cisco CallManager services restart spontaneously?

We are running cucm version 7.0.2. Yesterday we noticed the Cisco CallManager services stopped on the puplisher, so we restarted the services. Since that time the services restarted several times spontaneously. We also have one a subscriber in the claster which is working fine.

Any ideas?

Many thanks

Marian

[Mateusz Pagacz]

Marian,

Your CallManager service may be core dumping.

SSH to the pub and issue utils core active list to confirm this is indeed CallManager.

Next step is not trivial; use the time stamp you have there to correlate core to any particular activity you could have at that time.

CUCM 7.x is already End of Software Maintenance and approaching End of Life, so lastly review

http://www.cisco.com/web/software/282074295/105348/cucm-upgrade-readme-715bsu6a.pdf

to confirm if any of the defects listed there resembles the issue you are having.

If you find a match upgrade to the latest 7.1(5b)su6a and you _should_ be fine.

Otherwise this may require TAC assistance.

[bijaigurungNSC]

Hi Mateusz,

Thanks for suggestion. I have run the command and it looks very much like this bug 

"CSCte50152 : Memory leak in CCM due to Transient SIP Connections"

However, I don't see the line "operate new" which results in memory leak as suggested in "Trouble shooting core dump " section of CISCO FORUM.

Could you please have a look at this backtrace and further advise ?   Thanks in advance.

 backtrace
 ===================================
 #0  0x001db7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00fc67a5 in raise () from /lib/tls/libc.so.6
#2  0x00fc8209 in abort () from /lib/tls/libc.so.6
#3  0x0042e53b in __gnu_cxx::__verbose_terminate_handler () from /usr/local/cm/lib/libstlport.so.5.1
#4  0x0042c251 in __cxxabiv1::__terminate () from /usr/local/cm/lib/libstlport.so.5.1
#5  0x0042c286 in std::terminate () from /usr/local/cm/lib/libstlport.so.5.1
#6  0x0042c3cf in __cxa_throw () from /usr/local/cm/lib/libstlport.so.5.1
#7  0x00a30860 in xercesc_2_7::XMLString::parseInt () from /usr/local/cm/lib/libxerces-c.so.27
#8  0x09be13ae in XMLDoc::extractElement (node=0xb3d16460, elementName=0xa872d5c, targetVal=@0x6, required=true) at XMLDocHelper.cpp:458
#9  0x09be3b8d in RemoteCCDataPassthroughRequest::decode (node=0xb3d16460) at XMLDocHelper.cpp:1582
#10 0x09be5bdc in RemoteCCRequest::decode (node=0xb3d16380) at XMLDocHelper.cpp:731
#11 0x09be60bf in XMLDoc::decode (buf=) at XMLDocHelper.cpp:322
#12 0x0959b016 in SIPStationD::processRemoteCcRequest (this=0xb3a18aa8, signal=@0xb3926b60, addr=@0x2a33d20, msg=@0x2a33e70) at ProcessSIPStationD.cpp:13531
#13 0x0959c2b3 in SIPStationD::wait_SIPReferInd (this=0xb3a18aa8, s=@0xb3926b60) at ProcessSIPStationD.cpp:4098
#14 0x095b548c in SIPStationD::fireSignal (this=0xb3a18aa8, sdlSignal=@0xb3926b60) at /vob/ccm/Common/Include/Sdl/SdlProcessBase.hpp:174
#15 0x09e4a050 in SdlProcessBase::inputSignal (this=0xb3a18aa8, rSignal=0xb3926b60, traceType=SdlSystemLog::SignalRouterThread, highPriority=0, normalPriority=0, lowPriority=0, veryLowPriority=0, lazyPriority=0, dbUpdatePriority=0) at SdlProcessBase.cpp:396
#16 0x09e51e12 in SdlRouter::callProcess (this=0xde568e0, _sdlSignal=0xb3926b60, _deleteSignal=@0x2a34d97, _traceType=SdlSystemLog::SignalRouterThread, _hp=0, _np=0, _lp=0, _vlp=0, _lzp=0, _dbp=0) at SdlRouter.cpp:372
#17 0x09e51837 in SdlRouter::scheduler (sdlRouter=0xde568e0) at SdlRouter.cpp:282
#18 0x006b1ef3 in ACE_OS_Thread_Adapter::invoke (this=0xeec3e00) at OS_Thread_Adapter.cpp:94
#19 0x00672abf in ace_thread_adapter (args=0x0) at Base_Thread_Adapter.cpp:137
#20 0x004ae371 in start_thread () from /lib/tls/libpthread.so.0
#21 0x01066ffe in clone () from /lib/tls/libc.so.6

[Mateusz Pagacz]

What you posted matches https://tools.cisco.com/bugsearch/bug/CSCtq28305