I've put a fix into the CVS, maybe one of you can re-run the test if it a.) stopped the leak and b.) doesn't break anything. Thanks, Jan Jan Willamowius wrote: > 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/ ------------------------------------------------------------------------------ _______________________________________________________ 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/
