<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 09/20/2013 02:45 PM, Matthew Jordan
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAN2PU+56=0nciqVLbUGdzC3dHPVnH6sxxPUFsL5Nv1K0CCAosg@mail.gmail.com"
      type="cite">
      <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"><<a
                moz-do-not-send="true"
                href="mailto:marcotasto@libero.it" target="_blank">marcotasto@libero.it</a>></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'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> queue show 300<br>
              300 has 0 calls (max unlimited) in 'ringall' 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>   == Using SIP RTP CoS mark 5<br>
                  -- Executing [300@from-internal:1]
              NoOp("SIP/201-00000000", ""Called Queue 300") in new stack<br>
                  -- Executing [300@from-internal:2]
              Queue("SIP/201-00000000", "300,t,,") in new stack<br>
                  -- Started music on hold, class 'default', 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 "Busy" back from <a
                moz-do-not-send="true" 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'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.i686
              libxml2-2.7.6-12.el6_4.1.i686 ncurses-libs-5.7-3.20090208.el6.i686
              nss-softokn-freebl-3.14.3-3.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_blob
              (caller=<value optimized out>, agent=0x0,
              type=0x8f7c834, blob=0x9133668) at app_queue.c:1945<br>
              #3  0x0083ced4 in rna (rnatime=15000, qe=0xb70b3c88,
              peer=0x0, interface=0x91058ec "SIP/204",
              membername=0x8f6e0dc "SIP/204", autopause=1) at
              app_queue.c:4240<br>
              #4  0x0083e7c5 in wait_for_answer (qe=0xb70b3c88,
              outgoing=0x9105ca8, to=0xb70b3bb8, digit=0xb70b3bbf "",
              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 "",
              url=0xb70b3c26 "", 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=<value optimized out>) at app_queue.c:7597<br>
              #7  0x08188c44 in pbx_exec (c=0x910200c, app=0x8e3d240,
              data=0xb70b4ef8 "300,t,,") at pbx.c:1588<br>
              #8  0x08193a22 in pbx_extension_helper (c=0x910200c,
              con=0x9106db2, context=0x9102c70 "from-internal",
              exten=0x9102cc0 "300", priority=2, label=0x0,
              callerid=0x8e82968 "202", 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's a crash, so it's clearly a bug. Please go
              ahead and file an issue in the issue tracker.</div>
            <div style=""><br>
            </div>
            <div style="">
              Apparently o->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->call_next) {</div>
            <div><span class="" style="white-space:pre"> </span>rna(orig,
              qe, o->chan, o->interface,
              o->member->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->chan,
              outgoing, NULL, "NOANSWER");</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 moz-do-not-send="true"
                href="http://digium.com" target="_blank">http://digium.com</a>
              & <a moz-do-not-send="true"
                href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></pre>
    </blockquote>
    <br>
    Hi Matthew.<br>
    I've filled a bug in the issue tracker. It's the ASTERISK-22644<br>
    Thank you and best regards.<br>
    <br>
    Marco Signorini.<br>
    <br>
  </body>
</html>