if they went away by themselves they must not have been hung?<br><br><div class="gmail_quote">On Thu, Mar 5, 2009 at 5:39 PM, Nik Middleton <span dir="ltr">&lt;<a href="mailto:nik.middleton@noblesolutions.co.uk">nik.middleton@noblesolutions.co.uk</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Well if it&#39;s any consolation, I have a 4 day ish old copy of SVN and I<br>
have around 200 of these hung calls, though after an hour or so they did<br>
seem to clear.<br>
<br>
That said, FS made 138,330 call attempts today, not too shabby, and<br>
through out the call quality was as good as the first one.  Not sure how<br>
to debug this one.<br>
<br>
Version: FreeSWITCH Version 1.0.trunk (12276)<br>
<div><div></div><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a><br>
[mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a>] On Behalf Of Eric<br>
Liedtke<br>
Sent: 05 March 2009 23:23<br>
To: <a href="mailto:freeswitch-users@lists.freeswitch.org">freeswitch-users@lists.freeswitch.org</a><br>
Subject: Re: [Freeswitch-users] Hung Channels (SVN Rev 10231)<br>
<br>
Yup, as I mentioned to brian didn&#39;t want to clog jira with a bug that&#39;s<br>
been fixed or report against a rev 2k+ revs behind. I was trying to work<br>
through it as a learning exercise. And yeah I actually added a bunch of<br>
stuff to the list_sessions function to spit out a variety of associated<br>
variables for each session looking for a pattern somewhere to clue me<br>
into what might be happening.<br>
<br>
No proxy or bypass media here, just defaults.<br>
<br>
I will keep at it and once we update the production systems, if the<br>
problem persists I will open a bug in jira with all the neccessary<br>
goodies.<br>
<br>
Thanks<br>
-e<br>
<br>
It&#39;s seems fuzzy now but I think on Thu, Mar 05, 2009 at 05:55:33PM<br>
-0500 , Mathieu Rene said:<br>
&gt; HI,<br>
&gt;<br>
&gt; If you suspect a bug, the place to report it is JIRA. See:<br>
<a href="http://wiki.freeswitch.org/wiki/Reporting_Bugs" target="_blank">http://wiki.freeswitch.org/wiki/Reporting_Bugs</a><br>
&gt; .<br>
&gt; This gives the whole team a way of following up on issues.<br>
&gt;<br>
&gt; Also can you upgrade to svn trunk? A lot of fixes gets committed<br>
&gt; daily, so its good to stay up to date.<br>
&gt;<br>
&gt; As you seem familiar with GDB, you may symlink the .gdbinit file in<br>
&gt; the support-d/ folder to your home directory.<br>
&gt; This will give you some FS-specific macros such as &quot;list_sessions&quot;<br>
&gt; which will dump a list of uuids to session pointers.<br>
&gt;<br>
&gt; In your jira, make sure you include &quot;thread apply all bt&quot;,<br>
&gt; &quot;list_sessions&quot; and show channels (this one goes in FS) but PLEASE<br>
&gt; update to svn trunk and test again to see if it still happens.<br>
&gt;<br>
&gt; Also, are you using proxy/bypass media or just the default?<br>
&gt;<br>
&gt; Math<br>
&gt;<br>
&gt; On 5-Mar-09, at 5:38 PM, Eric Liedtke wrote:<br>
&gt;<br>
&gt; &gt; Greetings,<br>
&gt; &gt;<br>
&gt; &gt; I&#39;ve been using FS in production on this rev (I realize it&#39;s pretty<br>
<br>
&gt; &gt; far<br>
&gt; &gt; behind current) and it&#39;s been running well, save 1 issue.<br>
&gt; &gt;<br>
&gt; &gt; The basic setup is an SBC , 2 GiG-E ports, 1 public , 1 private. I<br>
&gt; &gt; have<br>
&gt; &gt; 2 sip profiles created , 1 per ip interface. This is being used to<br>
&gt; &gt; terminate traffic to a provider so calls are only 1 direction. They<br>
<br>
&gt; &gt; come<br>
&gt; &gt; into the private side profile, get routed via dialplan to the<br>
gateway<br>
&gt; &gt; defined in the external profile and on to the vendor. Pretty simple.<br>
&gt; &gt;<br>
&gt; &gt; I have noticed that under load (50 or so cps with ~800-900 bridged<br>
&gt; &gt; calls up)<br>
&gt; &gt; that over time some channels on the public side seem to get<br>
&gt; &gt; &quot;stuck&quot;.  Due to<br>
&gt; &gt; the nature of how this is being used , I would expect both sip<br>
&gt; &gt; profiles to show<br>
&gt; &gt; the same number of channels in use any time i do a &#39;sofia<br>
&gt; &gt; status&#39; ( or at least<br>
&gt; &gt; be within a channel or 2 of each other). However after a day of<br>
&gt; &gt; heavy use I had<br>
&gt; &gt; a disparity of ~250 channels. These extra channels also seem to put<br>
<br>
&gt; &gt; some<br>
&gt; &gt; continual load on the &#39;system cpu&#39; as well , reported via top.<br>
&gt; &gt;<br>
&gt; &gt; Of course due to the load on the box I have to keep logging turned<br>
way<br>
&gt; &gt; down. So I&#39;ve been trying to troubleshoot it as best I can.<br>
&gt; &gt;<br>
&gt; &gt; Last night I grabbed a core file and started in with GDB today. I<br>
&gt; &gt; found<br>
&gt; &gt; the 120 or so threads that represented real active calls when I took<br>
<br>
&gt; &gt; the<br>
&gt; &gt; corefile, I also found ~250 threads that appeared to be stuck in the<br>
&gt; &gt; CS_NEW state. The backtraces on all of them looks the same,<br>
&gt; &gt; annotated below.<br>
&gt; &gt;<br>
&gt; &gt; I walked through the code path by hand , based on the bt&#39;s and I<br>
&gt; &gt; don&#39;t see how<br>
&gt; &gt; this could be happening  unless it&#39;s a locking issue. But as far as<br>
<br>
&gt; &gt; I can tell<br>
&gt; &gt; each  session  has it&#39;s own mutex defined in the<br>
&gt; &gt; switch_core_session_t struct,<br>
&gt; &gt; so I wouldn&#39;t think they would be stepping on each other. I also<br>
&gt; &gt; would have expected<br>
&gt; &gt; if it were something of a deadlock nature it would stop processing<br>
&gt; &gt; calls all<br>
&gt; &gt; together.<br>
&gt; &gt;<br>
&gt; &gt; I grabbed the commands from the .gdbinit (super handy btw!!) and<br>
&gt; &gt; have been trolling<br>
&gt; &gt; through the variables to try to ascertain something about why these<br>
<br>
&gt; &gt; threads seem to<br>
&gt; &gt; be stuck, but am not having much luck even coming up with a scenario<br>
<br>
&gt; &gt; to try<br>
&gt; &gt; to replicate the issue.<br>
&gt; &gt;<br>
&gt; &gt; If anyone has any pointers as to where I might look next it would be<br>
<br>
&gt; &gt; greatly<br>
&gt; &gt; appreciated.<br>
&gt; &gt;<br>
&gt; &gt; We will be updating to the newest release soon, however I was hoping<br>
<br>
&gt; &gt; to nail down<br>
&gt; &gt; what is going so I can systematically replicate it and verify by<br>
&gt; &gt; testing in the lab<br>
&gt; &gt; that it is fixed , rather than just pushing the new release to<br>
&gt; &gt; produvction and hoping.<br>
&gt; &gt;<br>
&gt; &gt; Thanks in advance for any tips/pointers anyone may have.<br>
&gt; &gt;<br>
&gt; &gt; -e<br>
&gt; &gt;<br>
&gt; &gt; ......bt and bt full for a single &quot;hung&quot; thread<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; #0  0xb7fd5410 in __kernel_vsyscall ()<br>
&gt; &gt; #1  0xb7d14cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6<br>
&gt; &gt; #2  0xb7d4f1dc in usleep () from /lib/tls/i686/cmov/libc.so.6<br>
&gt; &gt; #3  0xb7ee02cd in switch_sleep (t=1000) at src/switch_time.c:143<br>
&gt; &gt; #4  0xb7e9da03 in switch_core_session_run (session=0x95fe270) at<br>
src/<br>
&gt; &gt; switch_core_state_machine.c:462<br>
&gt; &gt; #5  0xb7e9c765 in switch_core_session_thread (thread=0x9ada840,<br>
&gt; &gt; obj=0x95fe270) at src/switch_core_session.c:853<br>
&gt; &gt; #6  0xb7efd916 in dummy_worker (opaque=0x9ada840) at<br>
threadproc/unix/<br>
&gt; &gt; thread.c:138<br>
&gt; &gt; #7  0xb7e034fb in start_thread () from /lib/tls/i686/cmov/<br>
&gt; &gt; libpthread.so.0<br>
&gt; &gt; #8  0xb7d55e5e in clone () from /lib/tls/i686/cmov/libc.so.6<br>
&gt; &gt; (gdb) bt full<br>
&gt; &gt; #0  0xb7fd5410 in __kernel_vsyscall ()<br>
&gt; &gt; No symbol table info available.<br>
&gt; &gt; #1  0xb7d14cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6<br>
&gt; &gt; No symbol table info available.<br>
&gt; &gt; #2  0xb7d4f1dc in usleep () from /lib/tls/i686/cmov/libc.so.6<br>
&gt; &gt; No symbol table info available.<br>
&gt; &gt; #3  0xb7ee02cd in switch_sleep (t=1000) at src/switch_time.c:143<br>
&gt; &gt; No locals.<br>
&gt; &gt; #4  0xb7e9da03 in switch_core_session_run (session=0x95fe270) at<br>
src/<br>
&gt; &gt; switch_core_state_machine.c:462<br>
&gt; &gt;        exception = 0 &#39;\0&#39;<br>
&gt; &gt;        state = &lt;value optimized out&gt;<br>
&gt; &gt;        endstate = CS_NEW<br>
&gt; &gt;        endpoint_interface = &lt;value optimized out&gt;<br>
&gt; &gt;        driver_state_handler = (const switch_state_handler_table_t *)<br>
<br>
&gt; &gt; 0xb73b1720<br>
&gt; &gt;        application_state_handler = &lt;value optimized out&gt;<br>
&gt; &gt;        thread_id = 3085554955<br>
&gt; &gt;        env = {{__jmpbuf = {134603552, -1428248680, -1461722504,<br>
&gt; &gt; 9184, -1210273432, -1210014020}, __mask_was_saved = -1210034895,<br>
&gt; &gt; __saved_mask = {__val = {0, 3084988404, 3084937740, 3086469280,<br>
&gt; &gt; 9184, 1, 2976641592, 2833244792, 3086590960,<br>
&gt; &gt;        168036728, 3084937740, 2833244808, 3085923728, 1, 3086590960,<br>
<br>
&gt; &gt; 2833244840, 3086590960, 0, 134564192, 2833244840, 3085923728,<br>
&gt; &gt; 134564244, 3086590960, 2833244872, 3085887870, 134564240, 168036728,<br>
<br>
&gt; &gt; 3085458203, 3086590960, 2976606624,<br>
&gt; &gt;        134564192, 2833244904}}}}<br>
&gt; &gt;        sig = &lt;value optimized out&gt;<br>
&gt; &gt;        __func__ = &quot;switch_core_session_run&quot;<br>
&gt; &gt;        __PRETTY_FUNCTION__ = &quot;switch_core_session_run&quot;<br>
&gt; &gt; #5  0xb7e9c765 in switch_core_session_thread (thread=0x9ada840,<br>
&gt; &gt; obj=0x95fe270) at src/switch_core_session.c:853<br>
&gt; &gt;        session = (switch_core_session_t *) 0x95fe270<br>
&gt; &gt;        event = &lt;value optimized out&gt;<br>
&gt; &gt;        event_str = 0x0<br>
&gt; &gt;        val = &lt;value optimized out&gt;<br>
&gt; &gt;        __func__ = &quot;switch_core_session_thread&quot;<br>
&gt; &gt;        __PRETTY_FUNCTION__ = &quot;switch_core_session_thread&quot;<br>
&gt; &gt; #6  0xb7efd916 in dummy_worker (opaque=0x9ada840) at<br>
threadproc/unix/<br>
&gt; &gt; thread.c:138<br>
&gt; &gt; No locals.<br>
&gt; &gt; #7  0xb7e034fb in start_thread () from /lib/tls/i686/cmov/<br>
&gt; &gt; libpthread.so.0<br>
&gt; &gt; No symbol table info available.<br>
&gt; &gt; #8  0xb7d55e5e in clone () from /lib/tls/i686/cmov/libc.so.6<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Freeswitch-users mailing list<br>
&gt; &gt; <a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
&gt; &gt; <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
&gt; &gt;<br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
&gt; &gt; <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Freeswitch-users mailing list<br>
&gt; <a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
&gt; <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
&gt;<br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
&gt; <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>