未释放内存的起始地址在mtrace日志中未配对的“+”行中，用addr2line结合其后的返回地址（如0x40125c）可定位源码行号；需确保mtrace启用、符号完整、调用链清晰，并排除系统库干扰。

直接看日志里未配对的 + 行，地址字段就是未释放内存的起始地址，配合 addr2line 转成源码行号即可定位偏移位置。关键不在“找地址”，而在确保日志可读、符号可用、调用链完整。

确保 mtrace 日志生成有效

mtrace 只记录 malloc/calloc/realloc/free，不捕获 mmap、brk 或 C++ 的 new/delete。使用前必须：

• 包含头文件：#include <mcheck.h>
• 在 main() 开头调用 mtrace()，结尾调用 muntrace()
• 编译时加 -g 保留调试符号（不可省略），例如：gcc -g -o myapp myapp.c
• 运行前设置环境变量：export MALLOC_TRACE=./mtrace.log

从日志提取未释放地址并解析偏移

运行程序后，mtrace.log 内容类似：

= Start
@ ./myapp:[0x40123a] + 0x1f2a450 0x100
@ ./myapp:[0x40125c] + 0x1f2a560 0x200
@ ./myapp:[0x40127e] - 0x1f2a450
= End

其中每行 + 地址 大小 表示一次分配，- 地址 表示一次释放。未被 - 匹配的 + 行即为泄漏点——0x1f2a560 就是未释放内存的地址。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

用 addr2line 把该地址转回源码位置：

• addr2line -e ./myapp 0x40125c → 输出类似 myapp.c:42
• 注意：这里要传的是日志中 [0x40125c] 这个返回地址（即调用 malloc 的指令地址），不是堆地址 0x1f2a560

区分真实泄漏与干扰项

日志中可能混入系统库或第三方模块的分配，需聚焦你控制的代码路径：

• 检查 [0x40125c] 是否落在你的二进制段内（readelf -S ./myapp | grep '\.text' 查范围）
• 若地址落在 libc 或 libstdc++ 中，大概率不是你的泄漏，而是其内部缓存行为
• 多次运行对比：泄漏地址是否每次都在同一行？是否随循环次数线性增长？

配合进程内存指标交叉验证

单看 mtrace 不足以确认是否造成实际 RES 增长。需同步观察：

• pidstat -r -p $(pgrep myapp) 1：盯住 %MEM 和 minflt 是否持续上升
• pmap -x $(pgrep myapp) | grep total：看 RSS 是否与泄漏总量趋势一致
• /proc/$(pgrep myapp)/status 中的 VMData 字段：若该值同步上涨，说明堆泄漏是主因