[asterisk-bugs] [JIRA] (ASTERISK-26445) rtp: Deadlock in getting payload code
Ross Beer (JIRA)
noreply at issues.asterisk.org
Sun Oct 8 20:02:39 CDT 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-26445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ross Beer closed ASTERISK-26445.
--------------------------------
Resolution: Cannot Reproduce
I can no longer replicate the issue
> rtp: Deadlock in getting payload code
> -------------------------------------
>
> Key: ASTERISK-26445
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26445
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/RTP
> Affects Versions: 13.11.2
> Environment: Fedora 23
> Reporter: Ross Beer
> Assignee: Unassigned
> Attachments: backtrace-threads_2016-10-05-CLEAN.txt, backtrace-threads-CLEAN.txt, backtrace-threads-PJSIP.txt
>
>
> Asterisk deadlocks and no further processing can occur.
> This looks to be related to rtp_engine.c
> {noformat}
> #2 0x000000000053ce5a in __ast_rwlock_rdlock (filename=0x6f1e4b "rtp_engine.c", line=924, func=0x6f2ef0 <__PRETTY_FUNCTION__.16829> "ast_rtp_codecs_payload_code", t=0x7fe9945032f0, name=0x6f21a4 "&codecs->codecs_lock") at lock.c:911
> {noformat}
> I think this may have been caused by using hangup handlers on the channel. One before a dial and then another in the Dial b option subroutine. The hangup handlers call the same routine that updates the hangup reason for each channel:
> {noformat}
> #5 0x000000000058cac5 in ast_func_read (chan=0x7f4cc420fdb8, function=0x7f4d38cae0e0 "CHANNEL(rtcp,all)", workspace=0x7f4d38cad0c0 "", len=4096) at pbx_functions.c:617
> #6 0x0000000000590bb0 in pbx_substitute_variables_helper_full (c=0x7f4cc420fdb8, headp=0x7f4cc4210580, cp1=0x7f4d38caf260 "CDR(mos)=${CHANNEL(rtcp,all)};cr=${CHANNEL(audioreadformat)};cw=${CHANNEL(audiowriteformat)};cn=${CHANNEL(audionativeformat)}", cp2=0x7f4d38caf349 "", count=8182, used=0x7f4d38caf238) at pbx_variables.c:693
> #7 0x000000000059112b in pbx_substitute_variables_helper (c=0x7f4cc420fdb8, cp1=0x7f4d38caf260 "CDR(mos)=${CHANNEL(rtcp,all)};cr=${CHANNEL(audioreadformat)};cw=${CHANNEL(audiowriteformat)};cn=${CHANNEL(audionativeformat)}", cp2=0x7f4d38caf340 "CDR(mos)=", count=8191) at pbx_variables.c:790
> #8 0x0000000000575257 in pbx_extension_helper (c=0x7f4cc420fdb8, con=0x0, context=0x7f4cc4210770 "record-hangupcause", exten=0x7f4cc42107c0 "s", priority=4, label=0x0, callerid=0x7f4b60004a70 "<< PRIVATE INFORMATION REMOVED >>>", action=E_SPAWN, found=0x7f4d38cb1924, combined_find_spawn=1) at pbx.c:2873
> #9 0x00000000005788a2 in ast_spawn_extension (c=0x7f4cc420fdb8, context=0x7f4cc4210770 "record-hangupcause", exten=0x7f4cc42107c0 "s", priority=4, callerid=0x7f4b60004a70 "<< PRIVATE INFORMATION REMOVED >>>", found=0x7f4d38cb1924, combined_find_spawn=1) at pbx.c:4110
> {noformat}
> From the backtrace (attached) it looks like calling channel and the audio formats causes a lock.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list