[asterisk-bugs] [JIRA] (ASTERISK-26445) rtp: Deadlock in getting payload code

[Richard Mudgett (JIRA)]

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

Richard Mudgett commented on ASTERISK-26445:
--------------------------------------------

The [^backtrace-threads-PJSIP.txt] backtrace definitely shows a deadlock in the T.38 framehook between a pjsip serializer thread processing a reINVITE with SDP and the channel thread writing a frame in the T.38 frame hook.  The deadlock is between thread 3 and 4.  I have a patch for this up on gerrit against the ASTERISK-26974 issue I created as it is a different deadlock than this issue.

The other "CLEAN" backtraces give hints of a deadlock but I cannot find a circular locking because I cannot determine the deadlocked threads.  I cannot find the thread holding the lock that ast_rtp_codecs_payload_code() is trying to lock.  The backtraces are optimized and many threads have *too much* backtrace information deleted.  (I also cannot determine the deadlocking threads on the other private unredacted backtraces as they are also optimized.)


> 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)