[asterisk-dev] Asterisk 12 crashes with app queue and DND set on agent phone

Fri Sep 20 07:45:50 CDT 2013

On Fri, Sep 20, 2013 at 4:20 AM, Marco Signorini <marcotasto at libero.it>wrote:

> Hi All.
>
> I'm facing with a problem running a queue on Asterisk 12. It seems always
> replicable in my box.
> This is my setup:
>
> Asterisk SVN-branch-12-r399501M running on a CentOS 6.4 fresh install on
> bare Celeron machine.
>
> A queue defined as:
>
> [300]
> ringinuse=yes
> strategy=ringall
> timeout=15
> weight=0
> wrapuptime=0
>
> Two agents logged on that queue:
>
> *CLI> queue show 300
> 300 has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 0s
> talktime), W:0, C:0, A:0, SL:0.0% within 0s
>    Members:
>       SIP/204 (ringinuse enabled) (dynamic) (Not in use) has taken no
> calls yet
>       SIP/200 (ringinuse enabled) (dynamic) (Not in use) has taken no
> calls yet
>    No Callers
>
> The SIP/204 is a Grandstream GXP2000 and has the DND set so it will never
> ring.
>
> 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.
>
> *CLI>   == Using SIP RTP CoS mark 5
>     -- Executing [300 at from-internal:1] NoOp("SIP/201-00000000", ""Called
> Queue 300") in new stack
>     -- Executing [300 at from-internal:2] Queue("SIP/201-00000000",
> "300,t,,") in new stack
>     -- Started music on hold, class 'default', on SIP/201-00000000
>   == Using SIP RTP CoS mark 5
>     -- Called SIP/200
>   == Using SIP RTP CoS mark 5
>     -- Called SIP/204
>     -- SIP/204-00000002 connected line has changed. Saving it until answer
> for SIP/201-00000000
>     -- SIP/200-00000001 connected line has changed. Saving it until answer
> for SIP/201-00000000
>     -- Got SIP response 486 "Busy" back from 10.10.5.117:5066
>     -- SIP/204-00000002 is busy
>     -- Nobody picked up in 0 ms
>     -- SIP/200-00000001 is ringing
>     -- SIP/200-00000001 is ringing
>     -- Nobody picked up in 15000 ms
>     -- Nobody picked up in 15000 ms
> Segmentation fault
>
> I've generated a core dump and run the dgb to have the stack trace. Seems
> the PBX tries to manage a NULL channel.
>
> Here are the details:
>
> #0  0x080f4d2f in ast_channel_tech (chan=0x0) at channel_internal_api.c:877
> 877     {
> 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
> (gdb) bt
> #0  0x080f4d2f in ast_channel_tech (chan=0x0) at channel_internal_api.c:877
> #1  0x081d19e4 in ast_channel_snapshot_create (chan=0x0) at
> stasis_channels.c:184
> #2  0x0082b061 in queue_publish_multi_channel_**blob (caller=<value
> optimized out>, agent=0x0, type=0x8f7c834, blob=0x9133668) at
> app_queue.c:1945
> #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
> #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
> #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
> #6  0x0084416d in queue_exec (chan=0x910200c, data=<value optimized out>)
> at app_queue.c:7597
> #7  0x08188c44 in pbx_exec (c=0x910200c, app=0x8e3d240, data=0xb70b4ef8
> "300,t,,") at pbx.c:1588
> #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)
>     at pbx.c:4697
> #9  0x0819a3b1 in ast_spawn_extension (c=0x910200c, args=0x0) at pbx.c:5706
> #10 __ast_pbx_run (c=0x910200c, args=0x0) at pbx.c:6121
> #11 0x0819bc0d in pbx_thread (data=0x910200c) at pbx.c:6440
> #12 0x081edc3a in dummy_start (data=0x8e8ce70) at utils.c:1168
> #13 0x00f15a49 in start_thread () from /lib/libpthread.so.0
> #14 0x00209aae in clone () from /lib/libc.so.6
>

It's a crash, so it's clearly a bug. Please go ahead and file an issue in
the issue tracker.

Apparently o->chan can be NULL in the last ditch NOANSWER handler in
wait_for_answer:

if (!*to) {
for (o = start; o; o = o->call_next) {
rna(orig, qe, o->chan, o->interface, o->member->membername, 1);
}

publish_dial_end_event(qe->chan, outgoing, NULL, "NOANSWER");
}

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.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130920/9e0b1757/attachment.htm>