[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