[asterisk-bugs] [JIRA] (ASTERISK-22644) Crash with app queue and DND set on SIP agent phone

Matt Jordan (JIRA) noreply at issues.asterisk.org
Fri Oct 4 09:01:04 CDT 2013


    [ https://issues.asterisk.org/jira/browse/ASTERISK-22644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210777#comment-210777 ] 

Matt Jordan commented on ASTERISK-22644:
----------------------------------------

The backtrace is helpful, but the configuration I'm using still doesn't reproduce the problem.

Can you please attach the relevant portions of your {{sip.conf}}, {{queues.conf}}, and {{extensions.conf}}? I'd prefer to use your exact set up to try and reproduce the problem.
                
> Crash with app queue and DND set on SIP agent phone
> ---------------------------------------------------
>
>                 Key: ASTERISK-22644
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22644
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue, Core/Stasis
>    Affects Versions: 12.0.0-alpha1
>         Environment: Centos 6.4 i386 + Grandstream GXP2000 phones
>            Reporter: Marco Signorini
>            Assignee: Marco Signorini
>         Attachments: backtrace.txt
>
>
> 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-r400356M running on a CentOS 6.4 fresh install on bare Celeron machine.
> A queue defined as:
> {noformat}
> [300]
> ringinuse=yes
> strategy=ringall
> timeout=15
> weight=0
> wrapuptime=0 
> {noformat}
> Two agents logged on that queue:
> {noformat}
> *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
> {noformat}
> 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. 
> {noformat}
> *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 (core dumped)
> {noformat}
> 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:
> Core was generated by `asterisk -cvvvg'.
> Program terminated with signal 11, Segmentation fault.
> {noformat}
> #0  0x080f4a6f in ast_channel_tech (chan=0x0) at channel_internal_api.c:876
> 876     {
> 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  0x080f4a6f in ast_channel_tech (chan=0x0) at channel_internal_api.c:876
> #1  0x081d230d in ast_channel_snapshot_create (chan=0x0) at stasis_channels.c:184
> #2  0x00a6614f in queue_publish_multi_channel_blob (caller=<value optimized out>, agent=0x0, type=0x900491c, blob=0xb6b231a0) at app_queue.c:1955
> #3  0x00a77fc4 in rna (rnatime=15000, qe=0xb6867c88, peer=0x0, interface=0xb6b45964 "SIP/204", membername=0x8ff5c9c "SIP/204", autopause=1) at app_queue.c:4267
> #4  0x00a798b5 in wait_for_answer (qe=0xb6867c88, outgoing=0xb6b6f020, to=0xb6867bb8, digit=0xb6867bbf "", prebusies=0, caller_disconnect=0, forwardsallowed=1, ringing=0) at app_queue.c:4841
> #5  0x00a7b18a in try_calling (qe=0xb6867c88, opts=..., opt_args=0xb6868e04, announceoverride=0xb6867c27 "", url=0xb6867c26 "", tries=0xb6868e10, noption=0xb6868e0c, agi=0x0, macro=0x0, gosub=0x0, ringing=0) at app_queue.c:6239
> #6  0x00a7f25d in queue_exec (chan=0xb7421564, data=<value optimized out>) at app_queue.c:7624
> #7  0x08188a44 in pbx_exec (c=0xb7421564, app=0x8ff9c40, data=0xb6868ef8 "300,t,,") at pbx.c:1588
> #8  0x08193822 in pbx_extension_helper (c=0xb7421564, con=0xb6b7ef7a, context=0xb74221c8 "from-internal", exten=0xb7422218 "300", priority=2, label=0x0, callerid=0xb7407830 "201", action=E_SPAWN, found=0xb686b29c,
>     combined_find_spawn=1) at pbx.c:4697
> #9  0x0819a1b1 in ast_spawn_extension (c=0xb7421564, args=0x0) at pbx.c:5706
> #10 __ast_pbx_run (c=0xb7421564, args=0x0) at pbx.c:6121
> #11 0x0819ba0d in pbx_thread (data=0xb7421564) at pbx.c:6440
> #12 0x081ede4a in dummy_start (data=0xb7422b58) at utils.c:1169
> #13 0x00285a49 in start_thread () from /lib/libpthread.so.0
> #14 0x00ec5aae in clone () from /lib/libc.so.6
> {noformat}
> The issue was already posted on the dev-list and this is the comment from Matthew Jordan:
> {quote}
> 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:
> {noformat}
> 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");
> }
> {noformat}
> 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.
> {quote}
> Thanks! 
> Marco Signorini.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list