在QNX上做内存分析pmap是我第一个会翻出来的命令。这工具把进程的虚拟内存映射摊开给你看每一段地址空间对应什么对象、多大、什么权限、私有还是共享一眼就能扫出来。这篇就聊聊pmap的用法、输出含义和排障套路再延伸一个很实用的场景拿到单个线程的指令地址后怎么配合pmap快速定位代码。适合QNX嵌入式开发、系统集成和内存性能调优的兄弟参考也欢迎Linux转QNX的朋友对照着看。1. 为什么内存分析会从pmap开始1.1 QNX的内存管理更像是“谁申请、谁映射、谁负责”做嵌入式开发的人都知道QNX是微内核架构进程之间天然隔离一个进程崩掉不会把整个系统带崩。这个隔离的底层基础就是虚拟地址空间。QNX里每个进程都有自己的地址空间虚拟地址到物理地址的映射由内核维护。应用程序申请内存、加载共享库、打开共享内存对象最终都会反映到一段段的虚拟地址映射上。pmap干的事就是把进程的这一整套虚拟地址映射打印出来。它不像系统级的内存统计那样只给一个“用了多少、剩下多少”的总数而是精确到每一段地址区间这一块是可执行文件的代码段那一块是堆再往后是某个线程的栈还有哪些是mmap出来的共享内存。有了这个粒度你才能回答“内存到底被谁吃了”这种问题。很多从Linux过来的同事会觉得pmap眼熟Linux上确实也有同名命令。但QNX的pmap和Linux版有很多细节差异例如QNX系统里匿名内存经常映射到/dev/zero对象内核线程和用户线程的映射方式也完全不同所以不能拿着Linux的习惯硬套。后面我会专门讲这些差异。1.2 pmap和系统其他工具的边界QNX的内存分析工具不算多但每个都有明确分工。我自己的习惯是三层配合使用pidin mem看整机物理内存的账本总额、空闲、内核占用、缓存等属于第一层。top或pidin -p按进程维度看哪个进程占得多属于第二层。pmap -p PID看指定进程的虚拟地址空间明细属于第三层也最细。这三层缺一不可。直接拿pmap去逐段分析的前提是你已经确认目标进程是谁否则整个系统几百个进程你会被输出刷到怀疑人生。反过来如果你只知道系统内存紧张却不进到pmap里看映射明细也永远不知道是堆泄漏还是共享内存没清干净。所以pmap的价值不在“总览”而在“定界”。一旦锁定了进程pmap就是最核心的放大镜。2. pmap命令的基本用法与输出解读2.1 3步跑通第一条pmap命令拿PID、看映射、看汇总第一步先拿到目标进程的PID。QNX下最快的方式是$ pidin -p | grep my_app 12345 1 1 my_app第一列就是PID。如果进程名带后缀或者你知道完整路径也可以直接拼进程名。拿到PID后pmap的基础用法非常直接$ pmap -p 12345 Map for process 12345 (my_app) VA Object Size Type Prot Flags 00010000 /app/my_app 12k object r-- P 00014000 /app/my_app 148k object r-x P 00045000 /app/my_app 20k object rw- P 0006c000 /dev/zero 16k anon rw- P ...想一次看所有进程的映射可以加-a参数$ pmap -a这个输出会非常长生产环境慎用。我一般只在系统级排查找不到头绪时用而且一定会把结果重定向到文件再慢慢看$ pmap -a /tmp/all_pmaps.txt $ wc -l /tmp/all_pmaps.txt至于输出最后一行有些版本会给出一个total汇总有些版本不给。需要总量时别全靠最后一行用awk累加更稳。这里先记住pmap输出的Size单位通常是KB或字节不同版本有差异脚本处理时务必先确认单位。2.2 输出字段逐一说明这张表值得存pmap输出的每个字段都不是摆设。我整理了一张表新人和老手都值得留着字段含义实战价值VA这段映射的起始虚拟地址拿线程PC、SP对比区间时必用Object映射对应的对象名判断是代码、共享库、堆、栈还是设备Size映射区间大小找大块内存的第一筛选条件Type映射类型object/anon/device等区分文件映射和匿名内存Prot访问权限r/w/x组合判断是否为可执行代码、是否可写Flags内存属性常见P私有、S共享定位共享内存、判断私有匿名页VA列是十六进制地址排查时经常要拿它和一个线程的PC指针做范围匹配。Object列最直观看到/app/my_app说明落在可执行文件映射里看到/dev/zero通常是匿名内存看到/system/lib/libc.so.7说明在共享库代码里。Type列和Prot列往往是配合使用的。Type是object时Prot里出现r-x这基本就是纯代码段Type是anon时Prot是rw-通常是堆或者线程栈。Flags列的字符在不同QNX版本里不完全一致我看到过P/S的简写也见过共享内存显示为SH这里不纠结字符明白“私有”和“共享”的语义就行。2.3 几个典型的映射长什么样我把一个很典型的QNX进程映射摘下来逐段看00010000 /app/my_app 12k object r-- P 00014000 /app/my_app 148k object r-x P 00045000 /app/my_app 20k object rw- P 0006c000 /dev/zero 16k anon rw- P 00090000 /dev/shmem/my_ipc_buffer 256k object rw- S第一段是只读数据第二段是可执行的代码段第三段是读写数据段这三段都来自同一个可执行文件。第四段是匿名内存最典型的来源就是堆也可能是一个线程的栈。第五段是关键它映射的是一个名为/dev/shmem/my_ipc_buffer的共享内存对象Flags是S说明是共享映射多个进程看到的是同一份物理内存。如果把第五段忽略你会以为这个进程只占了几百KB但实际情况是共享内存可能占了物理内存大头。这种藏在映射里的对象只有pmap能清晰地暴露出来。后面定位高内存问题时会专门再讲。3. pmap实战从映射列表里挖内存问题3.1 一条排查链路系统、进程、映射三层过滤内存问题最怕一上来就扎进细节。我一般固定走一条三层过滤链路。第一层用pidin mem看系统物理内存总量和使用趋势$ pidin mem第二层用top -b -I 1抓几轮进程内存占用确定TOP进程$ top -b -I 1第三层锁定了PID之后再上pmap$ pmap -p 12345为什么强调顺序因为pmap给的是虚拟地址区间如果没有进程维度的物理内存数据做参照很容易被虚拟大小误导。一个进程可能映射了很大的地址空间但物理内存只占一小部分另一个进程虚拟映射不大RSS反而很高。只有先确认进程再用pmap看映射结构和增长点才不会白忙。三层链路走完后我会顺手把pmap的结果按Size排个序大块映射往前放$ pmap -p 12345 | sort -k3 -r | head -20这一步能快速暴露“某个/dev/zero的匿名映射异常扩大”或“某个shmem对象异常占用”的典型问题。3.2 识别堆增长、栈扩大、代码段异常pmap里最值得警惕的是匿名映射Object通常是/dev/zeroType是anon。这类映射的常见来源是malloc堆、线程栈、mmap匿名区。堆增长的特点是进程启动初期只有几段匿名映射运行一段时间后匿名映射的Size持续变大或者出现在不同地址区间的匿名映射数量变多。这个现象一旦和业务负载挂钩基本就是内存泄漏或者内存碎片化。你可以在固定时间点把pmap -p PID里的anon总大小累加出来画个趋势图比盯着RSS更有说服力。线程栈也有明显特征。QNX里每个线程栈通常是一段较小的匿名映射Size是几KB到几十KB。如果进程开了几十个线程pmap里就会看到一堆小Size的anon映射线程栈如果设置得特别大或者线程数量异常增长这些小映射的总量会非常可观。很多时候你以为的内存泄漏其实是线程数量失控。代码段异常不常见一旦出现就很严重。例如Object是某个可执行文件或共享库Prot却出现了rwx就要怀疑是不是运行时代码修改、JIT注入或者链接配置有问题。正常代码段要么是r-x要么是r--出现写权限一定要查清楚。3.3 共享内存最容易藏内存的地方共享内存在pmap里的特征最明显Object路径带/dev/shmem/Flags表示共享Type是object或anon。定位高内存问题时共享内存经常被忽略因为它在top的进程内存占用里未必算到进程头上却在全系统的pidin mem里占了真实物理内存。我处理过一个典型案例。系统启动后物理内存持续下降pidin mem显示共享内存区占用飙升但top列表里每个进程的内存看起来都很正常。最后逐进程运行pmap才发现某个守护进程创建了大量共享内存对象每次创建后没有在业务超时路径上执行shm_unlink导致同一份物理内存一直被映射着对象名从my_buffer递增到my_buffer_100。这类问题用pmap排查时直接过滤共享对象名$ pmap -p 12345 | grep shmem如果发现有大量仅序号不同的同名映射基本可以确定是句柄泄漏或者共享内存未释放。处理完代码后再用pmap复查确认映射数量恢复才算闭环。4. 进阶拿到单线程指令地址再和pmap对照定位4.1 什么情况下需要单线程PCpmap能告诉我们某段地址区间属于什么内存对象但它不会告诉你线程正在执行哪条指令。排障时经常遇到这样的问题线程卡死、CPU占用异常、崩溃core里的PC落在一个奇怪地址上。这时候只靠进程级pmap还不够你还得拿到“单个线程的指令地址”也就是PC指针。拿到PC之后再回到pmap里把地址往VA区间上一套就能快速判断这条指令是在主程序代码里、在某个共享库里还是在堆或栈上。如果是堆/栈上怀疑数据执行如果在共享库就按共享库来反推函数如果在主程序代码段就直接用addr2line定位到源码行。这个动作是QNX内存分析和崩溃分析的关键衔接点。4.2 3种方式抓线程PC/SPpidin、gdb、core方式一用pidin查线程详细信息。QNX的pidin -p接口可以指定线程ID某些版本会直接显示PC和SP$ pidin -p 12345 -t 3 TID 3: RUNNING pri: 8 (fifo) state: RUNNING stack: 0x1f800000 (16384 bytes) pc: 0x00014f88 sp: 0x1f80f000有的版本字段名和布局会不同但PC和SP这两个关键信息一般都会出现。这个方法适合在线查看不影响目标进程运行。方式二用gdb attach。QNX的gdb支持多线程调试attach到进程后再切到指定线程然后用x/i看当前指令(gdb) attach 12345 (gdb) info threads (gdb) thread 3 (gdb) x/i $pc这种方式最大的优点是能直接看到指令反汇编还能用bt打调用栈信息量比pidin大得多。缺点是attach会让进程暂停生产环境需要谨慎。方式三用core dump。如果进程已经崩溃直接用gdb加载core同样可以看每个线程的PC(gdb) core /var/log/core/my_app.core (gdb) info threads (gdb) thread 3 (gdb) x/i $pccore方式适合事后分析对线上干扰最小。我遇到疑难问题时三种方式经常配合先pidin快速抓现场再core做深度分析最后用gdb联调验证。4.3 把PC地址映射到代码pmap是中间那座桥拿到PC之后先别急着反汇编。我习惯把PC放在pmap的VA区间里过一遍。假设PC是0x00014f88pmap里有这一段00014000 /app/my_app 148k object r-x PPC落在0x00014000到0x00045000之间Object是/app/my_appProt是r-x说明线程正执行主程序的代码段。接下来可以放心地用addr2line反推源码行$ addr2line -e /app/my_app 0x00014f88 /app/src/foo.c:128如果PC落在/system/lib/libc.so.7对应的区间说明线程卡在库函数里那就要用libc的符号去对应$ addr2line -e /system/lib/libc.so.7 0x10481234如果PC落在/dev/zero这种匿名映射上Prot又是rwx那问题性质完全不同大概率是数据被当作代码执行了。此时x/i $pc看一眼汇编往往能看到0x41414141之类的异常指令模式。这就是把“单线程指令地址”和pmap放在一起分析的价值指令告诉你发生了什么pmap告诉你发生在什么内存对象里两者缺一不可。5. 用久了才总结出来的几条踩坑心得5.1 pmap看的是虚拟地址别直接当物理内存这是新人最容易踩的坑。pmap的Size是虚拟地址空间的区间大小不是实际消耗的物理内存。一个进程完全可以把一大段虚拟内存映射出来但真正访问过的物理页只有零星几页。你拿pmap的Size去和top里的RSS对比数字经常对不上这不是bug而是虚拟和物理的差异。真要评估物理内存占用QNX侧要参考pidin mem的进程统计或top里的RSS。pmap更适合做结构分析、增长趋势和对象类型判断。两个维度结合着看才能得到完整的内存画像。5.2 采样要成对时间点别乱pmap输出的只是某一瞬间的映射快照内存问题尤其是泄漏问题必须有多个时间点的对比才有效。我见过同事只跑了一次pmap看到一个大Size映射就断定泄漏结果是正常的预分配缓存后来白忙一场。正确做法是固定业务峰值和低谷两个时间点连续采样多轮$ pmap -p 12345 /tmp/map_t0.txt $ sleep 60 $ pmap -p 12345 /tmp/map_t1.txt $ diff /tmp/map_t0.txt /tmp/map_t1.txt对比diff才是排查泄漏的正确姿势。单看一次快照顶多能发现“这里有个大映射”看不出“这个映射是不是一直涨”。5.3 一个小脚本把pmap变成连续监控工具我习惯在目标机上放一个几行的shell脚本定期抓取关键进程的anon映射总量用最原始但可靠的方式捕捉趋势#!/bin/sh PID$1 INTERVAL10 while true; do TS$(date %H:%M:%S) ANON$(pmap -p $PID | awk /dev\/zero/ {sum $3} END {print sum}) SHM$(pmap -p $PID | awk /shmem/ {sum $3} END {print sum}) echo $TS anon$ANON shm$SHM sleep $INTERVAL done字段位置以实际pmap版本为准脚本本身不复杂但能把pmap从“一次性命令”变成“持续观察窗口”。排查线上问题时我先跑这个脚本记录基线再触发业务操作回来看曲线跳变定位速度会快很多。最后再分享一个习惯。每次pmap定位完问题我都会在代码注释里记一段当时的映射片段把“哪段地址、哪个对象、为什么异常”写清楚。时间久了这些片段比任何文档都好用下次再遇到类似问题一眼就能想起排查路径。这也是pmap用得越多越值钱的原因。