QNX内存分析：pmap命令详解与线程PC定位实战

在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指针做范围匹配。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/zero，Type是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 什么情况下需要单线程PC

pmap能告诉我们某段地址区间属于什么内存对象，但它不会告诉你线程正在执行哪条指令。排障时经常遇到这样的问题：线程卡死、CPU占用异常、崩溃core里的PC落在一个奇怪地址上。这时候只靠进程级pmap还不够，你还得拿到“单个线程的指令地址”，也就是PC指针。

拿到PC之后再回到pmap里，把地址往VA区间上一套，就能快速判断这条指令是在主程序代码里、在某个共享库里，还是在堆或栈上。如果是堆/栈上，怀疑数据执行；如果在共享库，就按共享库来反推函数；如果在主程序代码段，就直接用addr2line定位到源码行。这个动作是QNX内存分析和崩溃分析的关键衔接点。

4.2 3种方式抓线程PC/SP：pidin、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 $pc

core方式适合事后分析，对线上干扰最小。我遇到疑难问题时，三种方式经常配合：先pidin快速抓现场，再core做深度分析，最后用gdb联调验证。

4.3 把PC地址映射到代码，pmap是中间那座桥

拿到PC之后，先别急着反汇编。我习惯把PC放在pmap的VA区间里过一遍。假设PC是0x00014f88，pmap里有这一段：

00014000 /app/my_app 148k object r-x P

PC落在0x00014000到0x00045000之间，Object是/app/my_app，Prot是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 INTERVAL=10 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用得越多越值钱的原因。