Freeze runtime, build and artifact identity
Record the affected node, operating system, kernel, architecture, exact Asterisk version and branch, package or source-build identity, executable path, loaded modules, service start command, process ID, signal and synchronized incident time. A version label alone does not prove which binary and modules produced a dump.
Asterisk documents starting with -g for core-dump support, building with DONT_OPTIMIZE and retaining debugging symbols. Verify the actual running command and build settings. A configured flag, installed debug package and symbolized stack remain three different facts.
Establish where the operating system stores dumps
Inspect the deployed core-size limits, kernel.core_pattern, service-manager policy, destination ownership and available space before an incident. The pattern may name a file or hand the dump to a service such as systemd-coredump; do not assume a core appears in Asterisk’s working directory. Core artifacts can be very large.
Change kernel, service or storage policy only through an approved maintenance path. Record the expected naming rule, actual incident timestamp, process ID, signal, discovered artifact and its hash separately.
Preserve the matching binary and modules before change
After a crash, Asterisk directs operators to run ast_coredumper --tarball-coredumps promptly against the relevant path. The resulting package can include reports, the raw core, the Asterisk executable and installed modules. Preserve access controls, timestamps and hashes.
Do not update or replace the binary or modules before generating reports: mismatched executable, modules and symbols can make the dump or backtrace useless. Keep the original evidence immutable and perform analysis on an authorized copy.
Bound running and deadlock captures by impact
For a process that has not crashed, ast_coredumper --running --tarball-coredumps can capture a running instance, but Asterisk warns that the process and call handling are paused. The uppercase --RUNNING form skips confirmation; it is not a safe default. Use an explicit change window, owner, abort point and service-impact record.
DEBUG_THREADS, often paired with BETTER_BACKTRACES, can expose lock detail and enable core show locks on supported builds, but development options can reduce performance. Treat lock output as observed state, not proof of the causal thread.
Correlate backtrace, logs, packets and reproduction
A core dump, symbolized all-thread backtrace, Asterisk log, protocol trace and packet capture answer different questions. Validate that frames resolve to symbols, all relevant threads are included and incident time aligns with the exact log and packet interval. Missing symbols, truncated stacks or an unrelated dump remain explicit limitations.
Use a bounded logger channel and protocol debug only when authorized, reproduce only in a safe environment, then disable temporary verbosity. Asterisk’s issue guidance calls for factual environment, frequency, symptoms, reproduction and workaround evidence; causal attribution requires separate investigation.
Sanitize reports and keep raw memory private
Core files and tarballs can contain credentials, call data and other process memory. Review and redact text reports before public attachment. Asterisk says not to attach a raw core or full tarball publicly; use a secure transfer path only when the receiving maintainer provides instructions.
Preserve the private original, redacted copy, redaction log, recipient and retention decision separately. A complete report improves triage but does not establish availability, compatibility, a vendor finding or a corrective outcome.
Separate memory growth, corruption and crash evidence
The memory-growth guide keeps mmlog, refs, Valgrind findings, core dumps and causal conclusions as different artifacts.
Separate deadlock, crash and forced-core evidence
The deadlock-evidence guide keeps a running-process thread snapshot, held-lock view, all-thread backtrace, forced core and crash dump independently attributable.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk getting a backtrace ↗
- Asterisk collecting debug information ↗
- Asterisk issue guidelines ↗
- Asterisk CLI commands useful for debugging ↗
- Asterisk Menuselect options ↗
- Asterisk debugging overview ↗
- Asterisk memory leak debugging ↗
- Asterisk MALLOC_DEBUG compiler flag ↗
- Asterisk reference count debugging ↗
- Asterisk log security ↗
- Asterisk logging configuration ↗
- Asterisk legacy backtrace and deadlock workflow ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.