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. >>>> >>>> > > ------------------------------------------------------------------------------ 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/
