You are not logged in.
Pages: 1
Have core dump,
Although suspect it because of the memory leak from code,
From core backtrace cant figure it out was this the cause.
is there any gdb command or any utility command to check the memory used when core got generated.
How to confirm this was due to memory leak
Glimpse of backtrace of the core
#0 0x0000000000af40c7 in OS::TrapToDebugger () at ../../os_linux.cpp:4412
#1 0x0000000000af9385 in SaveDebugInfo (SignalNum=3, pSigInfo=0x7fffa937c5a0, pContext=0x7fffa937c470) at ../../os_linux.cpp:4057
#2 <signal handler called>
#3 std::_Rb_tree<unsigned int, std::pair<unsigned int const, CIFS_INCOMING_REQUEST*>, std::_Select1st<std::pair<unsigned int const, CIFS_INCOMING_REQUEST*> >, std::less<unsigned int>, __gnu_cxx::__pool_alloc<std::pair<unsigned int const, CIFS_INCOMING_REQUEST*> > >::find (this=0x3a18a28, __k=@0x7fffa937c8f8)
at /usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/stl_tree.h:494
#4 0x0000000000583e15 in CIFS_FILTER::GetNextOutgoingMID (this=0x3a17c60, SrcSide=FAST, pId=23735)
at /usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/stl_map.h:498
-------------------
Many Thanks for looking up .
Santosh
Last edited by santoshkumar (2013-03-19 06:19 AM)
Offline
If this is a background daemon process, I'd recommend ignoring SIGQUIT anyway... It's one of the signals (along with SIGINT, SIGHUP, SIGWINCH, and SIGPIPE) I always ignore in a daemon... (Actually, SIGPIPE I always ignore in clients as well...)
Offline
Pages: 1