[asterisk-bugs] [JIRA] (ASTERISK-26861) Deadlock in setting CDR variables

[Alex Hermann (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Hermann updated ASTERISK-26861:
------------------------------------

    Attachment: 26861-gdb-bt-307-29270.txt
                26861-gdb-threads.txt
                26861-gdb-bt-30-28043.txt
                26861-cli-threads.txt

The attached files contain:

1) output of cli "core show threads"
2) output of gdb "info threads"
3) backtrace of one of the threads waiting for the lock (30-28043)
4) backtrace of the process waiting on a condition involving (holding on to) the same lock (307-2970)


> Deadlock in setting CDR variables
> ---------------------------------
>
>                 Key: ASTERISK-26861
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26861
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Functions/func_cdr
>    Affects Versions: 13.14.0
>         Environment: Debian sid
>            Reporter: Alex Hermann
>         Attachments: 26861-cli-threads.txt, 26861-gdb-bt-30-28043.txt, 26861-gdb-bt-307-29270.txt, 26861-gdb-threads.txt
>
>
> When setting many CDR variables throughout the dialplan, at some point almost all channels/threads will wait on a lock that never gets released. SIP processing stops at that point.
> I don't know if it is relevant, but I set various CDR variables before the Dial command, in the contexts for Dial's 'G' and 'U' options and in the h exten for both the master and the outbound channels (by Dial's 'e' option).
> The problem only manifests itself during a bit of call load on the server (as does every deadlock). I can pretty reliable reproduce it within 15k calls at max 50 cps).
> {code}
> CLI> core show taskprocessors
> ...
> subm:cdr_engine-00000003                        11547039      22051       1439       4500       5000
> ...
> {code}
> I'll attach thread list and backtraces.



--
This message was sent by Atlassian JIRA
(v6.2#6252)