linux /proc/pid/maps 信息分析
linux-dash
A beautiful web dashboard for Linux
项目地址：https://gitcode.com/gh_mirrors/li/linux-dash
免费下载资源
·
接下来看看maps
[root@localhost proc]# cat /proc/1/maps
00110000-00111000 r-xp 00110000 00:00 0 [vdso]
0032b000-00347000 r-xp 00000000 fd:00 852733 /lib/ld-2.8.so
00347000-00348000 r--p 0001c000 fd:00 852733 /lib/ld-2.8.so
00348000-00349000 rw-p 0001d000 fd:00 852733 /lib/ld-2.8.so
0034b000-004ae000 r-xp 00000000 fd:00 852734 /lib/libc-2.8.so
004ae000-004b0000 r--p 00163000 fd:00 852734 /lib/libc-2.8.so
004b0000-004b1000 rw-p 00165000 fd:00 852734 /lib/libc-2.8.so
004b1000-004b4000 rw-p 004b1000 00:00 0
08048000-08067000 r-xp 00000000 fd:00 843075 /sbin/init
08067000-08068000 rw-p 0001e000 fd:00 843075 /sbin/init
08b42000-08b6a000 rw-p 08b42000 00:00 0 [heap]
b8046000-b8048000 rw-p b8046000 00:00 0
bfb4e000-bfb63000 rw-p bffeb000 00:00 0 [stack]
一共有6列
第一列代表内存段的虚拟地址
第二列代表执行权限，r，w，x不必说，p=私有 s=共享
不用说，heap和stack段不应该有x，否则就容易被xx，不过这个跟具体的版本有关
第三列代表在进程地址里的偏移量
第四列映射文件的主设备号和次设备号
通过 cat /proc/devices
得知fd是253 device-mapper
第五列映像文件的节点号，即inode
第六列是映像文件的路径
以前我很奇怪怎么会有两个相同的文件路径，原来
08048000-08067000 r-xp 00000000 fd:00 843075 /sbin/init
08067000-08068000 rw-p 0001e000 fd:00 843075 /sbin/init
一个是只读的，是代码段，一个是读写的，是数据段
至于为什么共享库分成了三个
0034b000-004ae000 r-xp 00000000 fd:00 852734 /lib/libc-2.8.so
004ae000-004b0000 r--p 00163000 fd:00 852734 /lib/libc-2.8.so
004b0000-004b1000 rw-p 00165000 fd:00 852734 /lib/libc-2.8.so
其中的004ae000-004b0000 r--p 00163000 fd:00 852734 /lib/libc-2.8.so
还是不能理解
最后看看神秘的memmap
可惜不是所有的版本都有这个文件，如同我这里的情况
只有口头说一说了，memmap需要和maps配合看
显示出来的每一行代表maps里的一个段
每一行的每一个数字，代表那个段里的一个页，段有多大，一行就有对应的多少个数字
如果这个数字是0，代表系统为其分配了虚拟内存，但是没有分配物理内存
如果有数字，则代表系统为其分配了物理内存，以及有多少个进程引用了这个页
当然，不会有负数出现
[root@localhost proc]# cat /proc/1/maps
00110000-00111000 r-xp 00110000 00:00 0 [vdso]
0032b000-00347000 r-xp 00000000 fd:00 852733 /lib/ld-2.8.so
00347000-00348000 r--p 0001c000 fd:00 852733 /lib/ld-2.8.so
00348000-00349000 rw-p 0001d000 fd:00 852733 /lib/ld-2.8.so
0034b000-004ae000 r-xp 00000000 fd:00 852734 /lib/libc-2.8.so
004ae000-004b0000 r--p 00163000 fd:00 852734 /lib/libc-2.8.so
004b0000-004b1000 rw-p 00165000 fd:00 852734 /lib/libc-2.8.so
004b1000-004b4000 rw-p 004b1000 00:00 0
08048000-08067000 r-xp 00000000 fd:00 843075 /sbin/init
08067000-08068000 rw-p 0001e000 fd:00 843075 /sbin/init
08b42000-08b6a000 rw-p 08b42000 00:00 0 [heap]
b8046000-b8048000 rw-p b8046000 00:00 0
bfb4e000-bfb63000 rw-p bffeb000 00:00 0 [stack]
一共有6列
第一列代表内存段的虚拟地址
第二列代表执行权限，r，w，x不必说，p=私有 s=共享
不用说，heap和stack段不应该有x，否则就容易被xx，不过这个跟具体的版本有关
第三列代表在进程地址里的偏移量
第四列映射文件的主设备号和次设备号
通过 cat /proc/devices
得知fd是253 device-mapper
第五列映像文件的节点号，即inode
第六列是映像文件的路径
以前我很奇怪怎么会有两个相同的文件路径，原来
08048000-08067000 r-xp 00000000 fd:00 843075 /sbin/init
08067000-08068000 rw-p 0001e000 fd:00 843075 /sbin/init
一个是只读的，是代码段，一个是读写的，是数据段
至于为什么共享库分成了三个
0034b000-004ae000 r-xp 00000000 fd:00 852734 /lib/libc-2.8.so
004ae000-004b0000 r--p 00163000 fd:00 852734 /lib/libc-2.8.so
004b0000-004b1000 rw-p 00165000 fd:00 852734 /lib/libc-2.8.so
其中的004ae000-004b0000 r--p 00163000 fd:00 852734 /lib/libc-2.8.so
还是不能理解
最后看看神秘的memmap
可惜不是所有的版本都有这个文件，如同我这里的情况
只有口头说一说了，memmap需要和maps配合看
显示出来的每一行代表maps里的一个段
每一行的每一个数字，代表那个段里的一个页，段有多大，一行就有对应的多少个数字
如果这个数字是0，代表系统为其分配了虚拟内存，但是没有分配物理内存
如果有数字，则代表系统为其分配了物理内存，以及有多少个进程引用了这个页
当然，不会有负数出现
GitHub 加速计划 / li / linux-dash
6
1
下载
A beautiful web dashboard for Linux
最近提交(Master分支：3 个月前 )
186a802e
added ecosystem file for PM2 4 年前
5def40a3
Add host customization support for the NodeJS version 4 年前
旨在为数千万中国开发者提供一个无缝且高效的云端环境，以支持学习、使用和贡献开源项目。
更多推荐
2
0- 0
已为社区贡献5条内容
所有评论(0)