<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 20, 2013 at 4:20 AM, Marco Signorini <span dir="ltr">&lt;<a href="mailto:marcotasto@libero.it" target="_blank">marcotasto@libero.it</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi All.<br>
<br>
I&#39;m facing with a problem running a queue on Asterisk 12. It seems always replicable in my box.<br>
This is my setup:<br>
<br>
Asterisk SVN-branch-12-r399501M running on a CentOS 6.4 fresh install on bare Celeron machine.<br>
<br>
A queue defined as:<br>
<br>
[300]<br>
ringinuse=yes<br>
strategy=ringall<br>
timeout=15<br>
weight=0<br>
wrapuptime=0<br>
<br>
Two agents logged on that queue:<br>
<br>
*CLI&gt; queue show 300<br>
300 has 0 calls (max unlimited) in &#39;ringall&#39; strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s<br>
   Members:<br>
      SIP/204 (ringinuse enabled) (dynamic) (Not in use) has taken no calls yet<br>
      SIP/200 (ringinuse enabled) (dynamic) (Not in use) has taken no calls yet<br>
   No Callers<br>
<br>
The SIP/204 is a Grandstream GXP2000 and has the DND set so it will never ring.<br>
<br>
As soon as a call enters in the queue, the SIP/200 starts ringing and the SIP/204 answers with a Busy back message. If the call is not answered, after the timeout period the PBX tries to contact the two agents but as soon as it contacts the SIP/204 it crashes.<br>

<br>
*CLI&gt;   == Using SIP RTP CoS mark 5<br>
    -- Executing [300@from-internal:1] NoOp(&quot;SIP/201-00000000&quot;, &quot;&quot;Called Queue 300&quot;) in new stack<br>
    -- Executing [300@from-internal:2] Queue(&quot;SIP/201-00000000&quot;, &quot;300,t,,&quot;) in new stack<br>
    -- Started music on hold, class &#39;default&#39;, on SIP/201-00000000<br>
  == Using SIP RTP CoS mark 5<br>
    -- Called SIP/200<br>
  == Using SIP RTP CoS mark 5<br>
    -- Called SIP/204<br>
    -- SIP/204-00000002 connected line has changed. Saving it until answer for SIP/201-00000000<br>
    -- SIP/200-00000001 connected line has changed. Saving it until answer for SIP/201-00000000<br>
    -- Got SIP response 486 &quot;Busy&quot; back from <a href="http://10.10.5.117:5066" target="_blank">10.10.5.117:5066</a><br>
    -- SIP/204-00000002 is busy<br>
    -- Nobody picked up in 0 ms<br>
    -- SIP/200-00000001 is ringing<br>
    -- SIP/200-00000001 is ringing<br>
    -- Nobody picked up in 15000 ms<br>
    -- Nobody picked up in 15000 ms<br>
Segmentation fault<br>
<br>
I&#39;ve generated a core dump and run the dgb to have the stack trace. Seems the PBX tries to manage a NULL channel.<br>
<br>
Here are the details:<br>
<br>
#0  0x080f4d2f in ast_channel_tech (chan=0x0) at channel_internal_api.c:877<br>
877     {<br>
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6_4.4.i686 libuuid-2.17.2-12.9.el6_4.3.<u></u>i686 libxml2-2.7.6-12.el6_4.1.i686 ncurses-libs-5.7-3.20090208.<u></u>el6.i686 nss-softokn-freebl-3.14.3-3.<u></u>el6_4.i686 sqlite-3.6.20-1.el6.i686 zlib-1.2.3-29.el6.i686<br>

(gdb) bt<br>
#0  0x080f4d2f in ast_channel_tech (chan=0x0) at channel_internal_api.c:877<br>
#1  0x081d19e4 in ast_channel_snapshot_create (chan=0x0) at stasis_channels.c:184<br>
#2  0x0082b061 in queue_publish_multi_channel_<u></u>blob (caller=&lt;value optimized out&gt;, agent=0x0, type=0x8f7c834, blob=0x9133668) at app_queue.c:1945<br>
#3  0x0083ced4 in rna (rnatime=15000, qe=0xb70b3c88, peer=0x0, interface=0x91058ec &quot;SIP/204&quot;, membername=0x8f6e0dc &quot;SIP/204&quot;, autopause=1) at app_queue.c:4240<br>
#4  0x0083e7c5 in wait_for_answer (qe=0xb70b3c88, outgoing=0x9105ca8, to=0xb70b3bb8, digit=0xb70b3bbf &quot;&quot;, prebusies=0, caller_disconnect=0, forwardsallowed=1, ringing=0) at app_queue.c:4814<br>
#5  0x0084009a in try_calling (qe=0xb70b3c88, opts=..., opt_args=0xb70b4e04, announceoverride=0xb70b3c27 &quot;&quot;, url=0xb70b3c26 &quot;&quot;, tries=0xb70b4e10, noption=0xb70b4e0c, agi=0x0, macro=0x0, gosub=0x0, ringing=0) at app_queue.c:6213<br>

#6  0x0084416d in queue_exec (chan=0x910200c, data=&lt;value optimized out&gt;) at app_queue.c:7597<br>
#7  0x08188c44 in pbx_exec (c=0x910200c, app=0x8e3d240, data=0xb70b4ef8 &quot;300,t,,&quot;) at pbx.c:1588<br>
#8  0x08193a22 in pbx_extension_helper (c=0x910200c, con=0x9106db2, context=0x9102c70 &quot;from-internal&quot;, exten=0x9102cc0 &quot;300&quot;, priority=2, label=0x0, callerid=0x8e82968 &quot;202&quot;, action=E_SPAWN, found=0xb70b729c, combined_find_spawn=1)<br>

    at pbx.c:4697<br>
#9  0x0819a3b1 in ast_spawn_extension (c=0x910200c, args=0x0) at pbx.c:5706<br>
#10 __ast_pbx_run (c=0x910200c, args=0x0) at pbx.c:6121<br>
#11 0x0819bc0d in pbx_thread (data=0x910200c) at pbx.c:6440<br>
#12 0x081edc3a in dummy_start (data=0x8e8ce70) at utils.c:1168<br>
#13 0x00f15a49 in start_thread () from /lib/libpthread.so.0<br>
#14 0x00209aae in clone () from /lib/libc.so.6<br></blockquote><div><br></div><div style>It&#39;s a crash, so it&#39;s clearly a bug. Please go ahead and file an issue in the issue tracker.</div><div style><br></div><div style>
Apparently o-&gt;chan can be NULL in the last ditch NOANSWER handler in wait_for_answer:</div><div style><br></div><div><span class="" style="white-space:pre">        </span>if (!*to) {</div><div><span class="" style="white-space:pre">                </span>for (o = start; o; o = o-&gt;call_next) {</div>
<div><span class="" style="white-space:pre">                        </span>rna(orig, qe, o-&gt;chan, o-&gt;interface, o-&gt;member-&gt;membername, 1);</div><div><span class="" style="white-space:pre">                </span>}</div><div><br></div><div><span class="" style="white-space:pre">                </span>publish_dial_end_event(qe-&gt;chan, outgoing, NULL, &quot;NOANSWER&quot;);</div>
<div style><span class="" style="white-space:pre">        </span>}</div><div style><br></div><div style>Since rna does more than just raise the Stasis messages regarding the status of the queue, the code that raises the message should probably be made tolerant to a NULL peer channel.</div>
<div style><br></div><div style>Matt</div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> &amp; <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>