|
From: Bob R. <bo...@br...> - 2005-08-26 02:24:28
|
On Fri, Aug 26, 2005 at 03:21:09AM +0200, Christian Parpart wrote: > Hi all, > > my daemon running on a production server having lots of I/O a day is > eating the RAM really wastinly. Well, of course, it'ms my fault, somehow, > but I didn't manage to get rid of all of them _yet_. > > Two of the memory leaks I reproduced using valgrind are as follows: > > ==16981== 84 bytes in 3 blocks are still reachable in loss record 11 of 28 > ==16981== at 0x1B9008C1: malloc (vg_replace_malloc.c:149) > ==16981== by 0x1D87B205: ??? > ==16981== by 0x1D87A1A9: ??? > ==16981== by 0x1D87A457: ??? > ==16981== by 0x1D87A950: ??? > ==16981== by 0x1D86F2CD: ??? > ==16981== by 0x1D86F5DA: ??? > ==16981== by 0x1D20ADFF: gethostbyname2_r (in /lib/libc-2.3.5.so) > ==16981== by 0x1D20ABCB: gethostbyname2 (in /lib/libc-2.3.5.so) > ==16981== by 0x1C39406B: System::Network::THostAddress::fromHostName(System::TStringBase<char> const&, System::Network::THostAddress::TFamily) (Utils.cp Is the line above part of your code? If so, the comment below applies here instead. > ==16981== by 0x1CB5E371: htutils::hasIP(System::TStringBase<char> const&) (htutils.cpp:102) It's possible that the leak is here. Do you allocate memory at this line? > ==16981== by 0x1CB5F3AA: htutils::htmlFormat(System::TStringBase<char> const&) (htutils.cpp:446) > ==16981== by 0x1CB92A5A: yacs::TMessageFormatter::formatChatCode(System::TStringBase<char> const&) (TMessageFormatter.cpp:54) > ==16981== by 0x1CB94CCD: System::TFunctorHandler<System::TFunctor<System::TStringBase<char>, System::TTypeList<System::TStringBase<char> const&, System: > ==16981== by 0x1CB93246: System::TFunctor<System::TStringBase<char>, System::TTypeList<System::TStringBase<char> const&, System::NullType> >::operator() > ==16981== by 0x1CB92428: yacs::TBasicMessageFormatter::formatMessage(System::TStringBase<char> const&, System::TStringBase<char> const&) (TMessageFormat > ==16981== by 0x1CB929F9: yacs::TMessageFormatter::format(System::TStringBase<char> const&, System::TStringBase<char> const&) (TMessageFormatter.cpp:50) > ==16981== by 0x1D5B7204: ??? > ==16981== by 0x1D5BE701: ??? > ==16981== by 0x1BA7F18D: System::TFunctor<void, System::TTypeList<yacs::TNetClientSession&, System::TTypeList<System::TDynamicArray<System::TStringBase< > ==16981== by 0x1BA6F471: yacs::TServer::handleCmd(yacs::TNetClientSession*, System::TStringBase<char> const&, System::TDynamicArray<System::TStringBase< > ==16981== by 0x1BA56F73: yacs::TNetClientSession::handleInput() (TNetClientSession.cpp:109) > ==16981== by 0x1BA56D24: yacs::TNetClientSession::onInput(System::Network::TNetworkStream*) (TNetClientSession.cpp:85) > ==16981== by 0x1BA5BAEA: System::TMemFunHandler<System::TFunctor<void, System::TTypeList<System::Network::TNetworkStream*, System::NullType> >, yacs::TN > ==16981== by 0x1C393206: System::TFunctor<void, System::TTypeList<System::Network::TNetworkStream*, System::NullType> >::operator()(System::Network::TNe > ==16981== by 0x1C39276A: System::Network::TNetworkStreamPrivate::onDataAvailableNow(int, System::IO::Unix::TPollMask) (TNetworkStreamPrivate.cpp:160) > ==16981== by 0x1C393873: System::TMemFunHandler<System::TFunctor<void, System::TTypeList<int, System::TTypeList<System::IO::Unix::TPollMask, System::Nul > ==16981== by 0x1C35F03D: System::TFunctor<void, System::TTypeList<int, System::TTypeList<System::IO::Unix::TPollMask, System::NullType> > >::operator()( > ==16981== by 0x1C367356: System::IO::Unix::TPollMgr::TInterest::notify(System::IO::Unix::TPollMask) (TPollMgr.cpp:232) > ==16981== by 0x1C36708A: System::IO::Unix::TPollMgr::processPending() (TPollMgr.cpp:193) > ==16981== by 0x1C366DEF: System::IO::Unix::TPollMgr::dispatchOnce(System::TTimeSpan) (TPollMgr.cpp:139) > ==16981== by 0x1BA6E07E: yacs::TServer::run() (TServer.cpp:383) > ==16981== by 0x8064F38: serve(System::TVarData const&) (yacsd.cpp:326) > ==16981== by 0x80667C7: main (yacsd.cpp:412) > > Interestingly, the man-page doesn't tell me anything about > gethostbyname_r() to be free()d afterwards. So, I don't > understand in why it leaks there. > However, this does not lead me into blindly assuming, > that it's glibc's fault here. But what could be wrong there? If you allocated memory at the line that I pointed out, then that's the memory that was most likely leaked. It can be difficult to track down *where* it leaked, but at least you know where it was allocated for. Bob Rossi |