确认内存泄漏需盯死rss（vmrss），在无业务增长等前提下观察其持续缓慢爬升且重启后重现相同斜率；用watch或/proc/pid/status监控，结合pmap -x比对[anon]/[heap]段kbytes增长，再以valgrind（需优雅退出）或mtrace（仅c）验证definitely lost或未配对malloc/free。
怎么确认某个进程真在泄漏内存
别看VIRT或free里的used，盯死RSS（也就是VmRSS）——它代表进程当前真实占用的物理内存页数。泄漏的表现是：无业务增长、无缓存预热、无连接数上升的前提下，RSS持续缓慢爬升；重启后归零，几小时内又回到相同斜率。
验证方法：
用watch -n 30 'ps -p <pid> -o pid,comm,rss,%mem --no-headers'</pid>每30秒抓一次；或者直接读/proc/<pid>/status</pid>里的VmRSS字段：cat /proc/<pid>/status | grep VmRSS</pid>。连续观察2–4小时，出现单调递增趋势才值得深入。
- Java/Golang等带GC的语言，
RSS涨不等于泄漏——得排除堆外内存（如ByteBuffer.allocateDirect）、JNI调用、或mmap文件映射未释放 -
top里按Shift+M排序后看到的RES列，和ps的rss是同一值，可信 - 如果
RSS稳定但VmSize（虚拟地址空间）持续增大，可能是mmap未munmap，不是传统“malloc泄漏”
pmap -x 看出哪块内存在偷偷长大
pmap -x <pid></pid>输出里真正要盯的是Kbytes列和Mapping列。泄漏常表现为[anon]段或[heap]段的大小随时间推移明显变大，尤其是多次执行后发现某段地址范围反复膨胀。
操作建议：
先记下初始值：pmap -x <pid> | grep -E "(^Address|anon|heap)"</pid>；
过10–15分钟再跑一次，对比Kbytes变化；
若某[anon]段从1280涨到3840，且没有对应业务动作（如加载大文件、建新连接），基本就是泄漏信号。
- 注意
pmap -XX <pid></pid>能显示页表级细节，如果看到大量1 page或4KB的[anon]映射，大概率是频繁malloc小块内存却没free -
pmap本身不报错、不告警，它只反映现状。必须人工比对多个时间点，不能单次快照下结论 - 服务类进程（如daemon）需确保
kill -15让其优雅退出，否则pmap看到的只是运行中快照，无法体现释放行为
valgrind --leak-check=full 必须等程序完整退出才出报告
valgrind不是实时监控工具，它是靠插桩拦截所有malloc/free调用，只有程序彻底退出时才汇总并报告“definitely lost”或“possibly lost”。所以对长期运行的服务，得发SIGTERM让它干净收尾，不能kill -9。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
关键命令：valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./your_program。
输出里重点看以definitely lost开头的块，后面跟着的堆栈会精确到example.c:42这种行号。
- 编译必须带
-g，否则堆栈里只有地址，没法定位源码 - 动态链接库路径要提前设好：
export LD_LIBRARY_PATH=./lib，不然valgrind可能找不到符号 - 性能开销极大（10–30倍慢），生产环境慎用；测试环境优先选
gcc -O0 -g编译，避免优化导致行号错位
mtrace 更轻量，但只适用于已知源码的C程序
mtrace是glibc自带的轻量方案，不用额外安装，适合快速验证一段C代码是否漏free。但它要求你在源码里手动插入#include <mcheck.h></mcheck.h>和mtrace()调用，且只能捕获malloc/realloc/free路径。
步骤：
1. 在main()开头加mtrace()；
2. 编译加-g；
3. 运行前设export MALLOC_TRACE=/tmp/mtrace.log；
4. 运行程序至结束；
5. 执行mtrace ./your_program /tmp/mtrace.log解析日志。
- 输出里会直接告诉你哪行
malloc没配对free，比如test.c:27 - 不支持C++的
new/delete，也不跟踪mmap/brk等系统调用 - 如果程序有多个退出路径（比如信号处理、异常分支），确保所有路径都走到
exit或return，否则mtrace日志不全
真正难的不是工具怎么用，而是区分“泄漏”和“glibc内存池暂不归还”。RSS高≠泄漏，得结合pmap看[anon]是否持续增长、valgrind是否报definitely lost、以及业务逻辑是否真的该释放——很多所谓“泄漏”，其实是没理解malloc背后那层内存管理器的行为。
