Re: [Openh323gk-users] Test the upcoming GNU Gatekeeper 2.3.2!

[Jan W. <ja...@wi...>]

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, ja...@wi..., http://www.gnugk.org/