Yuriy, it looks like the code for UDPProxySocket::BuildReceiverReport() that you submitted yourself is leaking. The endpoints I'm usually testing with don't trigger this code, but it looks like the allocated ReceiverReport never gets freed or maybe there is no need to allocate it at all. Maybe you can take a look at that code ? Regards, Jan Jan Willamowius wrote: > Andrew, > > as the manual say, ProxyAlways=1 is stronger than all other proxy > related switches. ;-) > > The leaks in your valgrind output going through PPluginManager are > those false positives I talked about and are no real leaks, but there > might actually be a leak BuildReceiverReport(). > > Regards, > Jan > > > Andrew Herdman wrote: > > Thanks Jan, I'll look at doing that. > > > > In the meantime I threw valgrind at an executable I had already, and ran > > 40 groups of 25 (1000) calls through it. Although proxy enable is 0, > > the calls were still proxied (bug?), I've attached my gatekeeper.ini, a > > statistics from the control interface and the vg output. I'm not a > > programmer vg looks like it found something, but I could be very wrong, > > feel free to tell me this data is useless without a debug build. GNUGK > > was built 20100413 at ~7am EDT. > > > > Oh and you were right about valguard and performance, it would peak at > > 155% CPU utilization on the test box, fortunately there are 4 full cores > > on the box, and 4 hyperthreaded ones. > > > > Andrew > > > > Gatekeeper(GNU) Version(2.3.2) > > Ext(pthreads=1,radius=0,mysql=1,pgsql=0,firebird=0,odbc=0,sqlite=0,large_fdset=4096,crypto/ssl=1,h46018=1,h46023=1) > > Build(Apr 13 2010, 13:38:46) Sys(Linux i686 2.6.26-2-686) > > > > > > -- Endpoint Statistics -- > > Total Endpoints: 4 Terminals: 3 Gateways: 1 NATed: 0 > > Cached Endpoints: 0 Terminals: 0 Gateways: 0 > > -- Call Statistics -- > > Current Calls: 0 Active: 0 From Neighbor: 0 From Parent: 0 > > Total Calls: 1000 Successful: 1000 From Neighbor: 0 From Parent: 0 > > Startup: Thu, 15 Apr 2010 07:24:19 -0400 Running: 0 days 00:54:13 > > > > cat gatekeeper.ini > > [Gatekeeper::Main] > > Fortytwo=42 > > Name=GNUGK000 > > Home=127.0.0.1,10.10.10.253 > > Bind=127.0.0.1,10.10.10.253 > > TimeToLive=600 > > ;TotalBandwidth=200000 > > StatusPort=7000 > > StatusTraceLevel=1 > > UseBroadcastListener=0 > > CompareAliasType=1 > > CompareAliasCase=0 > > TimestampFormat=MySQL > > > > > > [LogFile] > > Rotate=daily > > RotateTime=00:00 > > > > > > [RoutedMode] > > GKRouted=1 > > H245Routed=0 > > CallSignalPort=1720 > > CallSignalHandlerNumber=10 > > RtpHandlerNumber=8 > > AcceptNeighborsCalls=1 > > AcceptUnregisteredCalls=1 > > RemoveH245AddressOnTunneling=0 > > RemoveCallOnDRQ=0 > > DropCallsByReleaseComplete=1 > > SendReleaseCompleteOnDRQ=1 > > SupportNATedEndpoints=1 > > SupportCallingNATedEndpoints=1 > > TreatUnregisteredNAT=1 > > ForwardOnFacility=1 > > ShowForwarderNumber=0 > > Q931PortRange=20000-20999 > > H245PortRange=30000-30999 > > SetupTimeout=8000 > > SignalTimeout=30000 > > AlertingTimeout=60000 > > TcpKeepAlive=1 > > TranslateFacility=1 > > SocketCleanupTimeout=5000 > > EnableH46018=0 > > > > > > [Proxy] > > Enable=0 > > ProxyAlways=1 > > T120PortRange=40000-49999 > > RTPPortRange=50000-59999 > > ProxyForNAT=1 > > ProxyForSameNAT=1 > > DisableH460Call=1 > > DisableRTPQueuing=1 > > EnableRTPMute=0 > > > > > > [ModeSelection] > > > > [RasSrv::RRQFeatures] > > > > [RasSrv::ARQFeatures] > > > > [RasSrv::LRQFeatures] > > NeighborTimeout=2 > > SendRetries=2 > > ForwardHopCount=2 > > AcceptForwardedLRQ=1 > > ForwardResponse=0 > > ForwardLRQ=depends > > AcceptNonNeighborLRQ=1 > > AcceptNonNeighborLCF=1 > > > > > > [RoutingPolicy] > > default=internal,neighbor,explicit > > > > > > [RoutingPolicy::OnARQ] > > default=internal,neighbor,explicit > > > > > > [RoutingPolicy::OnLRQ] > > default=internal,neighbor,explicit > > > > > > [GkStatus::Auth] > > rule=allow > > > > [RasSrv::RewriteE164] > > > > [RasSrv::Neighbors] > > > > [RasSrv::GWPrefixes] > > MCU005-064034031178=1868901,1868902,1868903,1868904 > > > > [RasSrv::PermanentEndpoints] > > 10.10.10.178=MCU005-064034031178;1868901,1868902,1868903,1868904 > > > > [Gatekeeper::Auth] > > default=allow > > > > > > > > [CallTable] > > FileAcct=sufficient;start,stop,connect,on,off > > > > [FileAcct] > > DetailFile=/var/log/gnugk/CDR.txt > > StandardCDRFormat=1 > > TimestampFormat=MySQL > > Rotate=daily > > Rotatetime=00:00 > > > > > > [Gatekeeper::Acct] > > FileAcct=sufficient;start,stop,connect,on,off > > > > > > > > cat vg.log > > ==31059== Memcheck, a memory error detector. > > ==31059== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. > > ==31059== Using LibVEX rev 1854, a library for dynamic binary translation. > > ==31059== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. > > ==31059== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation > > framework. > > ==31059== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. > > ==31059== For more details, rerun with: -v > > ==31059== > > ==31059== My PID = 31059, parent PID = 3213. Prog and args are: > > ==31059== GNUGK20100413/File_System/usr/local/bin/gnugk > > ==31059== -t > > ==31059== --config > > ==31059== ./gatekeeper.ini > > ==31059== --output > > ==31059== /var/log/gnugk/gnugk.log > > ==31059== --pid > > ==31059== /var/run/gnugk/gnugk.pid > > ==31059== > > ==31059== > > ==31059== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 46 from 2) > > ==31059== malloc/free: in use at exit: 1,668,353 bytes in 26,303 blocks. > > ==31059== malloc/free: 29,145,541 allocs, 29,119,238 frees, > > 13,420,176,156 bytes allocated. > > ==31059== For counts of detected errors, rerun with: -v > > ==31059== searching for pointers to 26,303 not-freed blocks. > > ==31059== checked 1,013,672 bytes. > > ==31059== > > ==31059== 32 bytes in 2 blocks are definitely lost in loss record 11 of 61 > > ==31059== at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224) > > ==31059== by 0x832B9F5: > > PDevicePluginAdapter<PNatMethod>::CreateFactory(PString const&) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x834BE65: PPluginManager::RegisterService(PString > > const&, PString const&, PPluginServiceDescriptor*) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x8327537: > > _GLOBAL__I_PWLIB_gStaticLoader__STUN_PNatMethod (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x837DF7C: (within > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x804E277: (within > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x837DE98: __libc_csu_init (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x45783EB: (below main) (in /lib/i686/cmov/libc-2.7.so) > > ==31059== > > ==31059== > > ==31059== 5,176 bytes in 3 blocks are possibly lost in loss record 57 of 61 > > ==31059== at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224) > > ==31059== by 0x448699D: __gnu_cxx::free_list::_M_get(unsigned) (in > > /usr/lib/libstdc++.so.6.0.10) > > ==31059== by 0x836B252: > > __gnu_cxx::bitmap_allocator<PContainerReference>::allocate(unsigned) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x8365067: PContainerReference::operator new(unsigned) > > (in /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x8365548: PContainer::PContainer(int) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x836594A: PAbstractArray::PAbstractArray(int, int) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x836B5C8: PCharArray::PCharArray(int) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x8366716: PString::PString(char const*) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x834B6A7: > > _GLOBAL__I__ZN14PPluginManager20additionalPluginDirsE (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x837DF7C: (within > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x804E277: (within > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x837DE98: __libc_csu_init (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== > > ==31059== > > ==31059== 20,592 bytes in 429 blocks are possibly lost in loss record 59 > > of 61 > > ==31059== at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224) > > ==31059== by 0x80CB9E7: > > UDPProxySocket::BuildReceiverReport(RTP_ControlFrame const&, int, bool) > > (in /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x80DBE59: UDPProxySocket::ReceiveData() (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x80C84F5: ProxyHandler::ReadSocket(YaSocket*) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x8055126: SocketsReader::Exec() (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x80504F7: RegularJob::Run() (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x805141B: Worker::Main() (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x83467C7: PThread::PX_ThreadStart(void*) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x42354BF: start_thread (in > > /lib/i686/cmov/libpthread-2.7.so) > > ==31059== by 0x46426DD: clone (in /lib/i686/cmov/libc-2.7.so) > > ==31059== > > ==31059== > > ==31059== 1,218,576 bytes in 25,387 blocks are definitely lost in loss > > record 61 of 61 > > ==31059== at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224) > > ==31059== by 0x80CB9E7: > > UDPProxySocket::BuildReceiverReport(RTP_ControlFrame const&, int, bool) > > (in /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x80DBE59: UDPProxySocket::ReceiveData() (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x80C84F5: ProxyHandler::ReadSocket(YaSocket*) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x8055126: SocketsReader::Exec() (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x80504F7: RegularJob::Run() (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x805141B: Worker::Main() (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x83467C7: PThread::PX_ThreadStart(void*) (in > > /root/GNUGK20100413/File_System/usr/local/bin/gnugk) > > ==31059== by 0x42354BF: start_thread (in > > /lib/i686/cmov/libpthread-2.7.so) > > ==31059== by 0x46426DD: clone (in /lib/i686/cmov/libc-2.7.so) > > ==31059== > > ==31059== LEAK SUMMARY: > > ==31059== definitely lost: 1,218,608 bytes in 25,389 blocks. > > ==31059== possibly lost: 25,768 bytes in 432 blocks. > > ==31059== still reachable: 423,977 bytes in 482 blocks. > > ==31059== suppressed: 0 bytes in 0 blocks. > > ==31059== Reachable blocks (those to which a pointer was found) are not > > shown. > > ==31059== To see them, rerun with: --leak-check=full --show-reachable=yes > > > > > > > > > > Jan Willamowius wrote: > > > Andrew, > > > > > > to compile a debug executable, compile PTLib, H323Plus and GnuGk with > > > "make debug" instead of "make optnoshared". In addition to that you > > > need to copy the shared libraries for PTLib and H323Plus onto your > > > library path (a "make install" for both does that, but also copies > > > header files onto your system, so I would do it manually). > > > > > > Regards, > > > Jan > > > > > > Andrew Herdman wrote: > > > > > >> Jan; > > >> > > >> Certainly willing to help out here, can you tell us what if anything > > >> special is needed to build a debug executable? I use the instructions > > >> on the GNU/GK web page to build from CVS, the instructions for Ubuntu > > >> (but I use Debian). > > >> > > >> Thanks > > >> Andrew > > >> > > >> > > >> Jan Willamowius wrote: > > >> > > >>> Hi Yuriy, > > >>> > > >>> we both looked for a Radius leak a few months ago and couldn't locate > > >>> one, so I would need a much more detailed report how to replicate the > > >>> leak. > > >>> > > >>> Actually anybody using GnuGk can run a check for memory leaks: > > >>> There is a tool called 'Valgrind' and its included with most Linux > > >>> distributions. Simply compile a GnuGk debug executable and instead of > > >>> running it as always "gnugk -c file.ini -t", you run it under Valgrind: > > >>> "valgrind --log-file=vg.log --leak-check=yes gnugk -c file.ini -t" > > >>> > > >>> The you use GnuGk as usual and try to make all different sorts of calls > > >>> that might produce a memory leak. After shutting GnuGk down (eg. > > >>> with Ctrl-C), vg.log will contain a report with leaks. There will be a > > >>> few harmless things, like memory allocated on startup and never > > >>> released, but if you managed to trigger a real leak, it will be there, > > >>> too, along the source line that allocated it. > > >>> > > >>> The only downside is that Valgrind will reduce performance > > >>> dramatically, so you probably can't use this in a production > > >>> environment. > > >>> > > >>> Regards, > > >>> Jan > > >>> > > >>> > > >>> Georgiewskiy Yuriy wrote: > > >>> > > >>> > > >>>> Hi. > > >>>> > > >>>> There is memory leak steel exist somethere in radius support part. > > >>>> > > >>>> > > > -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
