Hi, on Windows the Win32 threading functions are used and on Unix GnuGk uses pthreads. Either way you need a thread library. If you can run GnuGk in 64 MB will depend on the CPU architecture. On x86_64 its probably not even going to load due to the memory occupied by the shared libraries. x86 32bit might be a bit better, not sure where PPC will clock in. It might need some tuning. You can limit the number of registrations or calls GnuGk will accept, but you currently can't limit the call volume by available memory. Regards, Jan Aristide Niyungeko wrote: > I thought it could be done; I have seen this: > > 2.3.4 version of GnuGK (windows XP). > (Gatekeeper(GNU) Version(2.3.4) > Ext(pthreads=0,radius=1, ... > (http://sourceforge.net/mailarchive/forum.php?thread_name=20110221225647.43c412ea%40janhh3.site&forum_name=openh323gk-users) > > But that is a windows build so it may be using a different thread library. > > This is the issue I was looking to solve: > > I have a gatekeeper running on a ppc system, OS is montavista cge linux, and the virtual memory limit is set to 64 M (ulimit -v 65536). > When I connect and disconnect 30 endpoints repeatedly using Win323, the gatekeeper hits the memory limit (64M) after about 10 minutes and dies. > > I observed two termination patterns > > For the first the gatekeeper shows this and terminates: > > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Aborted > > This is the gdb backtrace: > (gdb) bt > #0 0x0fb972d0 in raise () from /opt/montavista/current/montavista/cge/devkit/ppc/85xx/target/lib/libc.so.6 > #1 0x0fb98d04 in abort () from /opt/montavista/current/montavista/cge/devkit/ppc/85xx/target/lib/libc.so.6 > #2 0x0fef1ea4 in __gnu_cxx::__verbose_terminate_handler () from /opt/montavista/current/montavista/cge/devkit/ppc/85xx/target/usr/lib/libstdc++.so.6 > #3 0x0feef5c4 in ?? () from /opt/montavista/current/montavista/cge/devkit/ppc/85xx/target/usr/lib/libstdc++.so.6 > #4 0x0feef600 in std::terminate () from /opt/montavista/current/montavista/cge/devkit/ppc/85xx/target/usr/lib/libstdc++.so.6 > #5 0x0feef760 in __cxa_throw () from /opt/montavista/current/montavista/cge/devkit/ppc/85xx/target/usr/lib/libstdc++.so.6 > #6 0x0fef0178 in operator new () from /opt/montavista/current/montavista/cge/devkit/ppc/85xx/target/usr/lib/libstdc++.so.6 > #7 0x0fe65b20 in __gnu_cxx::__pool<true>::_M_reserve_block () from /opt/montavista/current/montavista/cge/devkit/ppc/85xx/target/usr/lib/libstdc++.so.6 > #8 0x1076c50c in __gnu_cxx::__mt_alloc<char, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate (this=0x1082b120, __n=4) > at /opt/montavista/cge51/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/../../../../target/usr/include/c++/4.2.0/ext/mt_allocator.h:709 > #9 0x1076c570 in PAllocatorTemplate<__gnu_cxx::__mt_alloc<char, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >, char>::allocate (this=0x1082a85d, v=4) > at /home/aniyungeko /PTLib_2.10.1/include/ptlib/object.h:989 > #10 0x1075f75c in PAbstractArray::InternalSetSize (this=0x10fafb60, newSize=1, force=false) at ptlib/common/contain.cxx:376 > #11 0x1075f98c in PAbstractArray::SetSize (this=0x10fafb60, newSize=1) at ptlib/common/contain.cxx:324 > #12 0x1074dcb0 in PArrayObjects::SetSize (this=0x10fb1648, newSize=1) at ptlib/common/collect.cxx:147 > #13 0x1069f234 in PASN_Array::operator= (this=0x10fb162c, other=@0x30c2db04) at ptclib/asner.cxx:2225 > #14 0x100a14d8 in H225_ArrayOf_AliasAddress::operator= (this=0x30c2db04) at /home/aniyungeko/ H323Plus_1.24.0/include/h225.h:3028 > #15 0x10112d54 in RegistrationRequestPDU::BuildRCF (this=0x10fa3f30, ep=@0x30c2ea5c) at RasSrv.cxx:2436 > #16 0x10121444 in RegistrationRequestPDU::Process (this=0x10fa3f30) at RasSrv.cxx:2267 > #17 0x101271c8 in RasMsg::Exec (this=0x10fa3f30) at RasSrv.cxx:357 > #18 0x10007818 in Jobs::Run (this=0x10fa3f50) at job.cxx:424 > #19 0x100099e4 in Worker::Main (this=0x10a27690) at job.cxx:193 > #20 0x107068ac in PThread::PX_ThreadStart (arg=0x10a27690) at ptlib/unix/tlibthrd.cxx:508 > #21 0x0ffcd72c in start_thread () from /opt/montavista/current/montavista/cge/devkit/ppc/85xx/target/lib/libpthread.so.0 > #22 0x0fc3edd0 in clone () from /opt/montavista/current/montavista/cge/devkit/ppc/85xx/target/lib/libc.so.6 > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > Line #20 and #21 are what prompted me that pthreads may be what causes the gatekeeper to use all the memory > > For the second termination pattern the gatekeeper displays this: > > assert.cxx(108) PWLib Assertion fail: Function pthread_create failed, file ptlib/unix/tlibthrd.cxx, line 577, Error=12 > Assertion fail: Function pthread_create failed, file ptlib/unix/tlibthrd.cxx, line 577, Error=12 > > <A>bort, <C>ore dump, <D>ebug? c > > Dumping core. > > No core was dumped in this case even though gatekeeper displayed the line above (and ulimt -c was unlimited) so I do not have a backtrace. > > The solution I would like to have is to make the gatekeeper reject any new requests when there is not enough memory left to process them. > > Thanks for your help, > > Aristide Niyungeko > -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________________ 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/
