You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
We had an audio conference (no video) with one moderator and many listeners. At some point no one was able to hear anything. When I attempted to restart freeswitch the error said that conference is still waiting for locks. The only way I was able to remove the locks was by running fsctl crash. After reviewing the core dump it seems like there was some kind of deadlock, see the attached backtrace.
It seems like thread 4 which is running the conference_thread_run is waiting for the audio_out_mutex for omember 0x7f3c8ae35910, while thread 162 which is running conference_member_del for member 0x7f3c8ae35910 is waiting on the conference mutex, which is most likely being held by thread 4 (otherwise it wouldn't have gotten to the point where it's attempting to acquire the audio_out_mutex).
I have attached the gdb output for the core dump
To Reproduce
I have not yet determined the exact steps to reproduce, but this happened twice in a row, for large conferences with many listeners joining and leaving constantly. The first time we observed this is after we recently upgraded to v1.10.13, we skipped several versions, so not sure with which version this issue started.
Expected behavior
Conferences should continue to produce audio regardless of how many listeners are joining and leaving
Description
We had an audio conference (no video) with one moderator and many listeners. At some point no one was able to hear anything. When I attempted to restart freeswitch the error said that conference is still waiting for locks. The only way I was able to remove the locks was by running fsctl crash. After reviewing the core dump it seems like there was some kind of deadlock, see the attached backtrace.
It seems like thread 4 which is running the conference_thread_run is waiting for the audio_out_mutex for omember 0x7f3c8ae35910, while thread 162 which is running conference_member_del for member 0x7f3c8ae35910 is waiting on the conference mutex, which is most likely being held by thread 4 (otherwise it wouldn't have gotten to the point where it's attempting to acquire the audio_out_mutex).
I have attached the gdb output for the core dump
To Reproduce
I have not yet determined the exact steps to reproduce, but this happened twice in a row, for large conferences with many listeners joining and leaving constantly. The first time we observed this is after we recently upgraded to v1.10.13, we skipped several versions, so not sure with which version this issue started.
Expected behavior
Conferences should continue to produce audio regardless of how many listeners are joining and leaving
Package version or git hash
1.10.13
Trace logs
N/A
backtrace from core file
backtrace2.zip
The text was updated successfully, but these errors were encountered: