Freeze one process and one growth interval
Record the node, exact Asterisk build, executable and module set, process ID, start time, workload, call flow, traffic rate, resident and virtual memory series, cgroup or service limits, swap, host pressure, recent change and the first observed symptom. Use synchronized timestamps and preserve the raw measurement source.
Do not merge several restarts, PIDs or hosts into one graph. A restart-related drop, high RSS or out-of-memory event remains different from a repeatable allocation or reference leak.
Prove the instrumented binary is actually running
Inspect build records and Menuselect state for MALLOC_DEBUG, then verify the loaded executable and core show help output for the documented memory commands. Confirm the expected log directory, service account, permissions, capacity and start time.
A selected compiler flag or installed binary does not prove the service loaded that binary. If mmlog is absent, correct only the first demonstrated build, install, runtime, path, permission or capacity gap; do not manufacture production load or force a crash.
Capture comparable allocation snapshots safely
At matched workload points, retain memory show summary output, any narrowly filtered allocation view, timestamp, uptime and resource impact. Enable allocation backtraces or at-exit output only with an explicit owner and stop condition because the documented overhead and volume can be material.
Do not run Valgrind on the same MALLOC_DEBUG build. If Valgrind is the selected method, create a separate supported test plan and record its substantial performance impact rather than comparing unlike runs as one experiment.
Preserve and interpret the reference log correctly
For an astobj2 lifetime question, verify whether the deployed version uses refdebug=yes or needs the older REF_DEBUG build path. Reproduce one bounded case, stop Asterisk gracefully as documented, preserve /var/log/asterisk/refs before another run overwrites it and process a copy with refcounter.py -n.
An invalid, skewed or apparently leaked object is a triage lead, not a final cause. An ungraceful stop can create false positives, while suppressed normal lifetimes and an incomplete reproduction can make the report inconclusive.
Align memory evidence with logs and workload
Capture the narrow logger interval requested for the issue, the active channel driver or call flow, relevant module inventory and one reproducible workload step. Disable elevated debug afterward and preserve logger configuration, rotation and dropped-output limitations.
Compare growth slope, allocation groups, object references and call lifecycle across like-for-like intervals. A correlation does not establish ownership or impact until the responsible code path and repeatable behavior are independently demonstrated.
Sanitize, escalate and verify one correction
Keep raw mmlog, refs, logs and measurements in restricted storage because Asterisk warns that logs and CLI output may include credentials and call history. Attach redacted text files rather than pasting long output, and include exact environment, version, modifications, third-party modules, call flow and reproduction details.
Apply one evidence-backed correction in an approved environment, then repeat the same measurement interval and a bounded ordinary-call workflow. No host, binary, allocation, reference, memory trend, leak, corruption, 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.
- Asterisk memory leak debugging ↗
- Asterisk MALLOC_DEBUG compiler flag ↗
- Asterisk reference count debugging ↗
- Asterisk collecting debug information ↗
- Asterisk issue guidelines ↗
- Asterisk Menuselect options ↗
- Asterisk log security ↗
- Asterisk logging configuration ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.