Asterisk getting locked randomly

PitzKey · July 29, 2026, 3:43pm

Hello,

Please see attached backtrace

From what I can tell: A thread completing a call transfer and a thread doing a routine RTP maintenance check each grabbed one lock and are waiting forever for the other’s and since one of them holds the global channel list, all 36 other threads (including every thread that answers new calls) are stuck in line behind them, so the whole PBX freezes.

Asterisk version 20.19.0

Has anyone encountered anything like that?

Thanks

jcolp · July 29, 2026, 3:48pm

github.com/asterisk/asterisk

[bug]: Deadlock between bridge and setting of RTP stats variables at hangup

opened 04:06PM - 03 May 26 UTC

closed 12:29PM - 06 May 26 UTC

phoneben

bug support-level-core

### Severity Trivial ### Versions 20.19.0 ### Components/Modules ao2_legacy… ### Operating Environment centos 7 ### Frequency of Occurrence One Time ### Issue Description Asterisk: 20.19.0 Channel storage backend: ao2_legacy Last reload: 2026-05-03 18:00:05.981181 Symptoms: - Asterisk stopped processing PJSIP taskprocessors. - Multiple AMI Action: Command / core show channel requests blocked in: internal_ao2_traverse -> channelstorage_ao2_legacy.c -> ast_channel_get_by_name - PJSIP channel allocation blocked in: lock_driver -> channelstorage_ao2_legacy.c:34 -> __ast_channel_alloc_ap -> chan_pjsip_new - Same condition persisted 5 minutes later, with additional blocked AMI threads. i have enabled ./menuselect/menuselect --enable channelstorage_cpp_map_name_id menuselect.makeopts but using ao2_legacy (was trying to debug another issue a few day ago and wanted to check if the cpp was a issue) ### Relevant log output ```shell ``` ### Asterisk Issue Guidelines - [x] Yes, I have read the Asterisk Issue Guidelines

github.com/asterisk/asterisk

[bug]: Calling ast_softhangup with channel lock held can cause deadlock

opened 03:10PM - 12 May 26 UTC

closed 09:12PM - 19 May 26 UTC

phoneben

bug support-level-core feedback-required

### Severity Minor ### Versions 20.19 ### Components/Modules channelstorage…_ao2_legacy ### Operating Environment centos 7 ### Frequency of Occurrence One Time ### Issue Description In channelstorage_ao2_legacy.c, both .rdlock and .wrlock are wired to the same lock_driver() function, and lock_driver() calls ao2_lock() on the channel storage container. The container is allocated with AO2_ALLOC_OPT_LOCK_MUTEX, so the legacy channel storage driver does not provide true read/write lock separation; read-style lookups and write-style channel insert/allocation paths are serialized on the same exclusive AO2 mutex. Under AMI load, especially when combining repeated core show channel lookups with Originate / Local-channel allocation paths, many threads can pile up behind the global channel storage container mutex. In the observed dumps, blocked waiters grew from about 20 to 31 within roughly five minutes, all waiting on the same mutex address, 0x31963f0. ### Relevant log output [core-asterisk-running-2026-05-12T14-12-42Z-brief-redacted.txt](https://github.com/user-attachments/files/27656734/core-asterisk-running-2026-05-12T14-12-42Z-brief-redacted.txt) [core-asterisk-running-2026-05-12T14-12-42Z-full-redacted.txt](https://github.com/user-attachments/files/27656736/core-asterisk-running-2026-05-12T14-12-42Z-full-redacted.txt) [core-asterisk-running-2026-05-12T14-12-42Z-info-redacted.txt](https://github.com/user-attachments/files/27656737/core-asterisk-running-2026-05-12T14-12-42Z-info-redacted.txt) [core-asterisk-running-2026-05-12T14-12-42Z-locks-redacted.txt](https://github.com/user-attachments/files/27656729/core-asterisk-running-2026-05-12T14-12-42Z-locks-redacted.txt) [core-asterisk-running-2026-05-12T14-12-42Z-thread1-redacted.txt](https://github.com/user-attachments/files/27656732/core-asterisk-running-2026-05-12T14-12-42Z-thread1-redacted.txt) [core-asterisk-running-2026-05-12T14-17-01Z-brief-redacted.txt](https://github.com/user-attachments/files/27656739/core-asterisk-running-2026-05-12T14-17-01Z-brief-redacted.txt) [core-asterisk-running-2026-05-12T14-17-01Z-full-redacted.txt](https://github.com/user-attachments/files/27656733/core-asterisk-running-2026-05-12T14-17-01Z-full-redacted.txt) [core-asterisk-running-2026-05-12T14-17-01Z-info-redacted.txt](https://github.com/user-attachments/files/27656738/core-asterisk-running-2026-05-12T14-17-01Z-info-redacted.txt) [core-asterisk-running-2026-05-12T14-17-01Z-locks-redacted.txt](https://github.com/user-attachments/files/27656731/core-asterisk-running-2026-05-12T14-17-01Z-locks-redacted.txt) [core-asterisk-running-2026-05-12T14-17-01Z-thread1-redacted.txt](https://github.com/user-attachments/files/27656735/core-asterisk-running-2026-05-12T14-17-01Z-thread1-redacted.txt) [README-redaction.txt](https://github.com/user-attachments/files/27656730/README-redaction.txt) ### Asterisk Issue Guidelines - [x] Yes, I have read the Asterisk Issue Guidelines

github.com/asterisk/asterisk

[bug]: Calling set_variable on PJSIP channel when originating with ARI with PJSIP_HEADER can result in deadlock

opened 08:02AM - 19 May 26 UTC

closed 03:30PM - 01 Jun 26 UTC

nnew2

bug support-level-core

### Severity Trivial ### Versions 20.18.2 ### Components/Modules pjsip ###… Operating Environment Debian 12 ### Frequency of Occurrence Occasional ### Issue Description [core-asterisk-running-2026-05-19T07-21-51Z-full.txt](https://github.com/user-attachments/files/27997389/core-asterisk-running-2026-05-19T07-21-51Z-full.txt) [core-asterisk-running-2026-05-19T07-21-51Z-info.txt](https://github.com/user-attachments/files/27997390/core-asterisk-running-2026-05-19T07-21-51Z-info.txt) [core-asterisk-running-2026-05-19T07-21-51Z-thread1.txt](https://github.com/user-attachments/files/27997393/core-asterisk-running-2026-05-19T07-21-51Z-thread1.txt) [core-asterisk-running-2026-05-19T07-21-51Z-locks.txt](https://github.com/user-attachments/files/27997391/core-asterisk-running-2026-05-19T07-21-51Z-locks.txt) [core-asterisk-running-2026-05-19T07-21-51Z-brief.txt](https://github.com/user-attachments/files/27997392/core-asterisk-running-2026-05-19T07-21-51Z-brief.txt) Hi, We've had an issue now a couple of times that appears to completely lock PJSIP (or more). I am not entirely sure what is locked in a full context but we know that PJSIP stops processing new calls and registers, and reloading of PJSIP configuration hangs. We are unable to replicate this, it appears to happen randomly during load. We have around 70 registered agents combined with a few SIP trunks. ### Relevant log output ```shell ``` ### Asterisk Issue Guidelines - [x] Yes, I have read the Asterisk Issue Guidelines

Fixed in 20.20.0.

PitzKey · July 29, 2026, 3:51pm

Thanks Josh.

Is this also related?

github.com/asterisk/asterisk

[bug]: Deadlock between RTP instance and ICE session

opened 01:24PM - 21 May 26 UTC

closed 11:56AM - 27 Jul 26 UTC

ServanVcare

bug support-level-core

### Severity Critical ### Versions 20.17.0, 22.9.0 ### Components/Modules c…han_pjsip, res_pjsip_session, res_pjsip, res_ari, res_ari_bridges, stasis, bridge_softmix, threadpool, taskprocessor, channel.c, channelstorage_ao2_legacy, astobj2 ### Operating Environment Ubuntu 22.04.5 LTS - 5.15.0-177-generic - x86_64 x86_64 x86_64 GNU/Linux ### Frequency of Occurrence Frequent ### Issue Description Asterisk appears to enter a deadlock or severe lock-contention state during concurrent processing of: - inbound PJSIP INVITEs - ARI bridges/addChannel operations - channel allocation - AO2 channel container traversal One thread becomes blocked in: __ast_channel_alloc_ap() during inbound SIP INVITE handling via: chan_pjsip_new() chan_pjsip_incoming_request() At the same time, other threads are blocked around: - AO2 channel traversal (internal_ao2_traverse) - bridge command synchronization (command_join) - ARI bridge addChannel operations Multiple threads accumulate waiting on futexes and mutexes, indicating a possible lock ordering inversion or deadlock involving: - channel allocation locks - AO2 container locks - bridge/stasis locks Symptoms: - inbound SIP calls stop progressing - ARI bridge operations hang - worker threads block indefinitely - Asterisk responsiveness degrades significantly Could this be a known deadlock or lock-order inversion between channel allocation, AO2 channel traversal, and ARI bridge operations during concurrent PJSIP INVITE handling? We would appreciate guidance on where the root cause is most likely located and whether there are known fixes, patches, or recommended debugging steps for this scenario. Is this something that should be investigated primarily in `channel.c`, `channelstorage_ao2_legacy`, `stasis/control`, or the ARI bridge handling path? [asterisk_bt_full 1.txt](https://github.com/user-attachments/files/28102376/asterisk_bt_full.1.txt) ### Relevant log output See above attachment: asterisk_bt_full 1.txt ### Asterisk Issue Guidelines - [x] Yes, I have read the Asterisk Issue Guidelines

jcolp · July 29, 2026, 3:51pm

To your backtrace? No, not from the bit of information I can get from it.

Topic		Replies	Views
Asterisk 22.8.2 hangs during ast_hangup() - AO2 channel container lock contention causes new calls to stop Asterisk Support	9	95	July 3, 2026
Asterisk stops working in two different ways Asterisk Support	1	322	October 13, 2011
Deadlock in asterisk Asterisk Support	2	252	June 2, 2006
Problem unstability asterisk Asterisk Support	2	271	July 5, 2007
Asterisk Dead Lock Asterisk SIP	8	960	October 19, 2020

Asterisk getting locked randomly

Related topics