[asterisk-bugs] [JIRA] (ASTERISK-22644) Crash with app queue and DND set on SIP agent phone
Marco Signorini (JIRA)
noreply at issues.asterisk.org
Mon Oct 14 04:49:03 CDT 2013
[ https://issues.asterisk.org/jira/browse/ASTERISK-22644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210891#comment-210891 ]
Marco Signorini commented on ASTERISK-22644:
--------------------------------------------
Hi Matt.
I've updated to Asterisk SVN-branch-12-r400872 and I can replicate the problem.
I'm uploading the whole SIP TCPDump capture (either in text format than in the binary format to be read with wireshark) and my relevant configuration files.
Thanks!
Marco Signorini.
> 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