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

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.

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

Freeze one incident without restarting away the evidence

Record the node, exact Asterisk build, executable and modules, process ID, uptime, first failed action, call symptoms, CLI response, service-manager state, CPU, memory, taskprocessor depth, channel and bridge counts, external dependency health, recent change and synchronized timestamps. Preserve existing logs and process metadata read-only.

Do not begin with restart, package update, broad reload, forced core or repeated debugger attachment. Those actions can end calls, alter thread state and erase the evidence that distinguishes overload, an external wait, a blocked console and a lock cycle.

Explain a missing core show locks command

Check core show settings, package and build records for DEBUG_THREADS, BETTER_BACKTRACES and DONT_OPTIMIZE, then match the running executable to the intended build. Verify current CLI help rather than assuming that an online page describes this package.

core show locks is unavailable without the required build support, and useful stacks depend on the documented environment and symbols. If rebuilding is justified, use a controlled reproduction because DEBUG_THREADS has a documented CPU cost; do not replace an active production binary solely to make one command appear.

Capture threads, locks and queue evidence in one window

Retain core show threads, core show locks when available, taskprocessor statistics, narrow channel or bridge counts, exact timestamps, uptime and workload. Note whether each command completed, returned no rows, stalled or was unavailable. Preserve raw output before any restart.

A blank lock report does not prove the absence of a deadlock, and a held lock does not prove a cycle or caller impact. Compare waiting and holding stacks, repeated snapshots and the affected behavior before selecting the next evidence owner.

Repair incomplete all-thread backtraces before inference

Use the current official backtrace procedure for the installed branch and preserve executable, PID, modules, debug-symbol packages, debugger command, attach result and output. Gather the all-thread stack close to the lock snapshot and inspect it for unresolved frames, optimized-out values, missing modules or the wrong process.

Do not mix a legacy command, another restart, a different binary or a later process into the same incident set. A partial stack is a collection limitation, not proof that the visible top frame owns the freeze.

Bound disruption, logging and artifact exposure

Before debugger attachment, forced core, instrumented replacement or elevated logging, document approval, call impact, maintenance window, storage capacity, abort threshold and rollback. Collect the minimum channel-driver or debug interval requested for the symptom and restore normal levels afterward.

Restrict core files, logs, CLI output and backtraces because they may contain memory, credentials, call history, identifiers and source paths. Prepare a redacted text attachment for escalation while retaining the original under controlled custody.

Validate cause and recovery as separate outcomes

Correlate a reproducible symptom, matching lock and all-thread evidence, responsible code path, build and module identity and an evidence-backed correction. Repeat the same bounded workload and ordinary-call acceptance case after the change while monitoring taskprocessor, thread, lock and logger state.

A successful restart, quiet period, patch installation or cleared queue does not by itself prove root cause or durable restoration. No host, process, thread, lock, debugger session, core, backtrace, call, deadlock, performance result, fix or support finding was inspected or tested for this diagnostic.

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 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 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.

Read guide →
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 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 →
Troubleshooting · Asterisk 22 res_pjsip configuration, current taskprocessor CLI debugging documentation and the project taskprocessor source reviewed October 6, 2026; commands, fields, queue ownership and safe operating limits still depend on the installed branch, modules, workload and support policy

Asterisk taskprocessor queue reached its high-water mark

Identify the alerting taskprocessor, preserve queue depth and timing evidence, and separate the producer, consumer and PJSIP overload response before changing limits.

Read guide →
Troubleshooting · 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 core dump is missing or the backtrace is incomplete

Find the first evidence gap across incident identity, dump policy, matching binaries and modules, debug symbols, report generation, thread coverage, logs and secure escalation.

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 →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →