VoIP.infoThe independent guide to business communications.
VoIP.info Guide

Asterisk deadlock evidence: DEBUG_THREADS, core show locks and all-thread backtraces

Investigate an apparently frozen Asterisk process without treating an unavailable CLI, one lock row, one thread stack or a forced core as proof of a deadlock or root cause.

Reviewed 2026-10-29Current official Asterisk CLI-debugging, backtrace, deadlock, issue-guideline, logging, Menuselect and log-security documentation was reviewed October 29, 2026; installed branch, packaging, compiler flags, symbols, executable, process, thread, lock, workload, taskprocessor state, debugger behavior, core-dump policy, logger output, reproduction, causal finding, correction and support response remain deployment-specific; the legacy deadlock page is explicitly scoped to Asterisk versions before 13.14.0 and 14.3.0 and is retained only for its version-labelled workflow; no Asterisk host, FreePBX system, binary, compiler flag, symbol, process, thread, lock, debugger session, core dump, backtrace, log, call, deadlock, fix or support case was inspected or testedAdvancedDocumentation based · not lab tested

Define the freeze symptom before naming a deadlock

Record node, operating system, exact Asterisk branch and build, package or source provenance, executable, process ID, start time, recent change, workload, call symptoms, remote-CLI behavior, CPU, memory, taskprocessor depth, service-manager state and synchronized incident window. Distinguish a stopped process, overloaded host, blocked console, taskprocessor backlog, external dependency wait and apparent call freeze from a demonstrated lock cycle.

A process that accepts TCP or retains a PID is not proven healthy. An unresponsive CLI, queued work, high CPU, quiet log or restart recovery does not by itself prove a deadlock, the responsible thread or a fixed service.

Prove the diagnostic build and command contract

Asterisk documents that core show locks requires a build with DEBUG_THREADS, and says useful lock stacks generally also need BETTER_BACKTRACES; the current backtrace guidance separately requires retained debug symbols and recommends DONT_OPTIMIZE. Preserve Menuselect state, exact installed binary, running executable and core show settings build options separately.

The documentation warns that DEBUG_THREADS can reduce performance, primarily through CPU consumption. A selected compiler option, installed package or available source tree does not prove that the running service contains the option, symbols or command.

Capture threads, locks and workload as one incident set

core show threads inventories running threads without special compiler flags. With the documented build prerequisites and supported library environment, core show locks can show held locks and the stacks that led to lock calls. Capture each command, timestamp, process uptime, workload and output status in the same narrow window.

An empty lock view, one held lock or one waiting thread is not a causal deadlock finding. Align the lock snapshot with taskprocessor statistics, channel and bridge counts, narrow logs and the user-visible symptom without assuming that every busy or waiting thread belongs to the affected call.

Pair lock output with a symbolized all-thread backtrace

Asterisk deadlock guidance calls for an all-thread debugger backtrace gathered immediately before or after core show locks. Preserve the exact executable, process ID, modules, symbol packages, debugger command, attach and detach result, output file and clock relationship. Check for optimized-out frames and unresolved symbols before escalation.

The legacy deadlock page is explicitly scoped to releases before 13.14.0 and 14.3.0. Use the current backtrace guidance for a current branch and treat older commands as version-labelled evidence rather than a universal script.

Control debugger, core and logging impact

Debugger attachment, forced core collection, instrumented builds, high verbosity and protocol traces can pause processing, consume CPU or storage, expose data or terminate service depending on the selected method and platform. Use an approved reproduction or maintenance window with owner, abort threshold, free-space check, call-impact plan and rollback.

Collect only the requested logger and channel-driver interval, then restore normal levels. Do not force a core, restart Asterisk or broaden debug merely to obtain an artifact when a less disruptive thread and lock snapshot answers the evidence question.

Sanitize, escalate and verify a correction separately

Asterisk issue guidance asks for attached debug files rather than long pasted output. Logs, CLI output, core files and backtraces can expose credentials, call history, identifiers, memory contents and source paths. Keep restricted originals, make a reviewed redacted issue copy and record custody, recipients and retention.

Escalate exact environment, modifications, third-party modules, reproduction, lock output and symbolized all-thread stacks. A developer hypothesis, patch, restart or disappearing symptom remains separate from a repeatable causal finding and a verified ordinary-call restoration.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Guide · Current Asterisk backtrace, logging, issue-report, debugging-CLI and Menuselect documentation was reviewed October 29, 2026; installed branch, packaging, executable, modules, debug symbols, build flags, service manager, kernel core policy, filesystem capacity, crash signal, core file, stack frames, locks, logs, packet capture, reproduction, production impact, root cause, fix and support response remain deployment-specific; no Asterisk host, FreePBX system, binary, module, debug-symbol package, kernel setting, core dump, backtrace, log, packet, crash, deadlock, live call or support case was inspected or tested

Asterisk crash, core dump and backtrace evidence

Prepare, capture, preserve, inspect and share Asterisk crash or deadlock evidence without assuming a core file is complete, symbols match or the root cause is known.

Read guide →
Guide · Current official Asterisk memory-leak, MALLOC_DEBUG, reference-count, logging, issue-guideline, Menuselect and log-security documentation was reviewed October 29, 2026; installed branch, packaging, compiler flags, allocator, module set, process accounting, workload, baseline, observation interval, mmlog, reference log, logger output, Valgrind run, performance impact, reproduction, causal finding, correction and support response remain deployment-specific; no Asterisk host, FreePBX system, binary, module, compiler flag, process, allocation, reference, log, call, memory-growth event, leak, corruption, crash, fix or support case was inspected or tested

Asterisk memory-growth evidence: MALLOC_DEBUG, mmlog and reference counts

Investigate rising Asterisk memory without treating one process counter, allocation snapshot, mmlog entry or reference record as proof of a leak or root cause.

Read guide →
Guide · Current Asterisk CLI, PJSIP troubleshooting, call-identifier and console-verbosity documentation reviewed September 30, 2026; no host, CLI, module, object, channel or call tested

Asterisk CLI: inspect the running system

Establish the exact running instance, loaded modules, PJSIP object graph and live call state before using a command that changes service.

Read guide →
Guide · Current Asterisk logging, runtime command, logger.conf, debug-collection, call-identifier and console-verbosity documentation reviewed September 30, 2026; no process, logger, trace, storage path or call tested

Asterisk logging without permanent debug overload

Map configured destinations, console levels, call identifiers and a bounded protocol trace without leaving sensitive debug collection active.

Read guide →
Guide · Asterisk 22 LTS

Install Asterisk 22 LTS: a controlled source-build workflow

Pin a supported Asterisk 22 release, review every dependency and build choice, then prove the installed binary and running service before adding calls.

Read guide →
Guide

PBX logs and packet captures: useful evidence with limited exposure

Collect enough to diagnose a call while protecting identities, secrets and audio.

Read guide →
Troubleshooting · Current official Asterisk CLI-debugging, backtrace, deadlock, issue-guideline, logging, Menuselect and log-security documentation was reviewed October 29, 2026; installed branch, packaging, compiler flags, symbols, executable, process, thread, lock, workload, taskprocessor state, debugger behavior, core-dump policy, logger output, reproduction, causal finding, correction and support response remain deployment-specific; the legacy deadlock page is explicitly scoped to Asterisk versions before 13.14.0 and 14.3.0 and is retained only for its version-labelled workflow; no Asterisk host, FreePBX system, binary, compiler flag, symbol, process, thread, lock, debugger session, core dump, backtrace, log, call, deadlock, fix or support case was inspected or tested

Asterisk appears deadlocked, core show locks is missing or the backtrace is incomplete

Find the first gap across process state, workload, diagnostic build, lock snapshot, symbols, all-thread stacks, logging, artifact custody and safe restoration.

Read guide →