[asterisk-dev] Asterisk 12 crashes with app queue and DND set on agent phone
Marco Signorini
marcotasto at libero.it
Thu Oct 3 05:10:41 CDT 2013
On 09/20/2013 02:45 PM, Matthew Jordan wrote:
>
>
>
> On Fri, Sep 20, 2013 at 4:20 AM, Marco Signorini <marcotasto at libero.it
> <mailto: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
> <http://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
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
Hi Matthew.
I've filled a bug in the issue tracker. It's the ASTERISK-22644
Thank you and best regards.
Marco Signorini.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131003/d1ce8ba4/attachment.html>
More information about the asterisk-dev
mailing list