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/
