[asterisk-bugs] [JIRA] (ASTERISK-29474) core: Exceptionally long queue length with Record and ConfBridge

[N A (JIRA)]

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

N A commented on ASTERISK-29474:
--------------------------------

Just directly swapping Record out with MixMonitor does not trigger queue warnings but does spam the following similarly if debug is on:

[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:336 audiohook_read_frame_both: Failed to get 160 samples from write factory 0x7f34f4026ea8
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:275 audiohook_read_frame_both: Read factory 0x7f34f4026468 and write factory 0x7f34f4026ea8 both fail to provide 160 samples
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:336 audiohook_read_frame_both: Failed to get 160 samples from write factory 0x7f34f4026ea8
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:275 audiohook_read_frame_both: Read factory 0x7f34f4026468 and write factory 0x7f34f4026ea8 both fail to provide 160 samples
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:336 audiohook_read_frame_both: Failed to get 160 samples from write factory 0x7f34f4026ea8
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:275 audiohook_read_frame_both: Read factory 0x7f34f4026468 and write factory 0x7f34f4026ea8 both fail to provide 160 samples
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:336 audiohook_read_frame_both: Failed to get 160 samples from write factory 0x7f34f4026ea8
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:275 audiohook_read_frame_both: Read factory 0x7f34f4026468 and write factory 0x7f34f4026ea8 both fail to provide 160 samples
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:336 audiohook_read_frame_both: Failed to get 160 samples from write factory 0x7f34f4026ea8
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:275 audiohook_read_frame_both: Read factory 0x7f34f4026468 and write factory 0x7f34f4026ea8 both fail to provide 160 samples
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:336 audiohook_read_frame_both: Failed to get 160 samples from write factory 0x7f34f4026ea8
[Jun 15 14:50:01] DEBUG[7549][C-00000033]: audiohook.c:275 audiohook_read_frame_both: Read factory 0x7f34f4026468 and write factory 0x7f34f4026ea8 both fail to provide 160 samples

This spams the console whenever MixMonitor is active.

MixMonitor() isn't an optimal replacement for Record() in this use case, but this suggests that there may be some issues with Record() that cause things to go wrong in conjunction with ConfBridge.

> core: Exceptionally long queue length with Record and ConfBridge
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-29474
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29474
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_confbridge
>    Affects Versions: 18.4.0
>            Reporter: N A
>            Assignee: Unassigned
>         Attachments: confbridge.conf, core-asterisk-running-2021-06-10T12-30-28-0400-brief.txt, core-asterisk-running-2021-06-10T12-30-28-0400-full.txt, core-asterisk-running-2021-06-10T12-30-28-0400-info.txt, core-asterisk-running-2021-06-10T12-30-28-0400-locks.txt, core-asterisk-running-2021-06-10T12-30-28-0400-thread1.txt, core-asterisk-running-2021-06-10T12-38-12-0400-brief.txt, core-asterisk-running-2021-06-10T12-38-12-0400-full.txt, core-asterisk-running-2021-06-10T12-38-12-0400-info.txt, core-asterisk-running-2021-06-10T12-38-12-0400-locks.txt, core-asterisk-running-2021-06-10T12-38-12-0400-thread1.txt, core-asterisk-running-2021-06-11T00-06-54+0000-brief.txt, core-asterisk-running-2021-06-11T00-06-54+0000-full.txt, core-asterisk-running-2021-06-11T00-06-54+0000-info.txt, core-asterisk-running-2021-06-11T00-06-54+0000-locks.txt, core-asterisk-running-2021-06-11T00-06-54+0000-thread1.txt, core-asterisk-running-2021-06-11T00-17-11+0000-brief.txt, core-asterisk-running-2021-06-11T00-17-11+0000-full.txt, core-asterisk-running-2021-06-11T00-17-11+0000-info.txt, core-asterisk-running-2021-06-11T00-17-11+0000-locks.txt, core-asterisk-running-2021-06-11T00-17-11+0000-thread1.txt, core-asterisk-running-2021-06-11T17-18-53+0000-full.txt, debug_log_123456.txt, debug_threads.txt, extensions.conf, extensions.conf, locks.txt
>
>
> It's our friend "__ast_queue_frame: Exceptionally long queue length queuing to..." again.
> I'm mark this as app_confbridge related because 99% of the time, deadlocks on my systems are caused by ConfBridge and using other applications if possible does not cause this issue at all.
> This issue happens with ConfBridges in multiple different scenarios - below is one that replicates every single time:
> - bring another channel playing audio into a confbridge
> - bring another channel that records locally into the confbridge, but muted
> - have that original channel join that ConfBridge
> All is good. Now, as soon as, from another phone, I join that same confbridge, even if muted, this whole thing happens immediately until at least after all channels and the bridge are torn down. Usually Asterisk crashes fairly quickly when this kind of thing happens; in this specific scenario, it doesn't crash quickly but it does basically kill both channels effectively and these warnings continue until everything involved is torn down, though sometimes this persists 10-20 seconds after that. In certain other similar scenarios, Asterisk usually crashes within a minute as CPU usage climbs to 100%.
> This is just one scenario that leads to this deadlock, but it can happen in several different ways. Typically it happens when multiple parties are in this aforementioned bridge using ConfBridge. Replacing ConfBridge with ChanSpy in places where possible is enough to make the issue disappear, hence why this seems to be a bug with app_confbridge.
> Attached are output from astcoredumper and core show locks during the deadlock.
> In this particular deadlock, there seems to be some kind of infinite loop caused by infinite progress updates, although I only see the infinite progress stuff when Asterisk is compiled with DONT_OPTIMIZE and DEBUG_THREADS. Regardless, this deadlocks occurs.



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