Freddy, that is very good testing! I'm currently busy with non-GnuGk projects, but it would be great if you could pinpoint the place in the code where we are still missing a check for a failed socket open based on your current test setup. We fixed a lot of those moving from 2.2.0 to 2.2.1 but obviously not all and you should be able to get a backtrace from your segfault. After that we need a strategy how to deal with an out-of-socket situation best. If we have only reached the limit per thread we might actually be able to dynamically start another handler thread and be fine. But it could also be a system limit we are reaching and then we'd need a strategy to handle current calls and registrations and avoid new calls. Quite a bit of work, but doable. So short, Jan Freddy Parra wrote: > Test on generating calls for Gnugk Version 2.2.2: > > > > The following test was performed: > > > > 1.) I used screens to create a separate session on Linux and set > ulimit to be 65 sockets for gnugk to run with. > > 2.) I had signaling handlers set to 15 and with h225 routed and h245 > being tunneled. No media proxying. > > 3.) Generated 3 sets of 10 calls each to Gnugk. > > 4.) During the second set of initiated calls Gnugk displayed the > following error: > > > > Assertion fail: Operating System error, file tlibthrd.cxx, line 730, > Error=24 > > > > <A>bort, <C>ore dump, <I>gnore? > > > > 5.) Once this error appear one could continue to send calls to the > system, but no more Sockets were being created and released when > > Checking the total sockets with lsof - p 29621 | wc -l. > > > > 6.) I repeated this same test a few more times and the same error > appeared. > > > > I then decided to perform the test on an old version of 2.2b5 that I > had been using for many months before moving to 2.2.2 > > The same errors occur as in 2.2.2. I also did not see any new sockets > being created or released when issuing lsof - p 29621 | wc -l. > > The status port was blank with _ characters appearing. > > > > I used the following Call Generator command. > > > > callgen323 -m 10 -r 10 --tmaxest 5 --tmincall 3 --tmaxcall 3 > --tminwait 1 --tmaxwait 1 -u gen2 -g xxx.xxx.xxx.xxx CISCO5850E > > > > > > > > > > ________________________________ > > From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx > [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of > Freddy Parra > Sent: Wednesday, February 23, 2005 11:04 AM > To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Subject: RE: Non-Responsive > > > > Here are some current results: > > > > When max sockets are reached the following behavior was noted: > > > > For this test I had the following conditions set: > > > > 1.) I used screens to create a separate session window on Linux and > set ulimit to be 60 sockets for gnugk to run with. > > 2.) I had signaling handlers set to 15 and with h225 routed and h245 > being tunneled. No media proxying. > > 3.) I was able to create 3 telnet instances to the status port and on > the 4th instance I got a blank telnet response. This meant I ran out > of sockets > > which is the state I wanted gnugk to be in. > > 4.) When I issued a reload on one of the telnet sessions all endpoints > that were registered suddenly unregistered. > > 5.) I retested the same case scenario and this time had a segmentation > fault (core dump). > > 6.) I performed the following test a few times over and the same > scenarios played out, with endpoints un-registering and segmentation > fault happening. > > > > > > I'm in the process of creating some test with the call generator and > see what the behavior is when calls are being sent to the system when > max sockets are reached. > > > > Freddy > > > > -----Original Message----- > From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx > [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of > Freddy Parra > Sent: Tuesday, February 22, 2005 6:53 PM > To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Subject: RE: Non-Responsive > > > > Hi Todd, > > > > That's interesting. I was thinking of maybe running the call generator > > program that comes with openh323 and setting the ulimit for total > > sockets on gnugk to a very small number like 20, then generating like > 50 > > or more calls at the same time using the call generator. Maybe like > this > > we can duplicate this behavior and see if this is the actual problem. > I > > will try later on today if I find something and post my findings. > > > > Freddy > > > > > > > > -----Original Message----- > > From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx > > [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of R. > > Todd Wallace > > Sent: Tuesday, February 22, 2005 5:55 PM > > To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > > Subject: RE: Non-Responsive > > > > Something that was noticed was that the GNU had a ton of sockets in > wait > > state. It looks like there was a blip in IP and these sockets did not > > get > > released and the GNU had them in wait state. > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real > users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick > > > > _______________________________________________________ > > > > List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > > Archive: http://sourceforge.net/mailarchive/forum.php?forum_id...49 > > Homepage: http://www.gnugk.org/ > > -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.willamowius.de/ ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&opÌk _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id?49 Homepage: http://www.gnugk.org/
