嵌入式系统中的应用程序库可能比较少,没有像PC那么多的命令,也不可能安装一些复杂的工具
基本原则: 找内存泄漏,则必然要求信息能定位到进程级别
(1)查看进程相关的信息:如它的环境变量
cat /proc/pid/environ
可以知道它有哪些环境变量getenv也可以做到
(2)查看进程打开的文件:
cat /proc/pid/fd
可以验证某些东西
(3)查看进程的状态
cat /proc/pid/stat
思考:ps的实现是通过读取proc文件系统并分析得到的
(4)查看进程的内存的使用情况
cat /proc/pid/statm 可以从另一个侧面反映进程的状况
statm信息输出说明(7列)
size resident shared
程序的大小 常驻内存空间大小 与其它进程共享的内存页数
trs drs lrds dt
代码段占内存页数 数据/堆栈段占内存的页数 引用库占用内存的大小 脏页数量
引用库内存页数包括了与其它进程共享的页数二者相减,则可得到自己独立的库页数
(5)查看进程的另一个状态信息
cat /proc/pid/status
VmSize: 进程虚拟地址空间的大小
VmLck: 进程已锁住的物理内存的大小,锁住的物理内存不能交换到硬盘
VmData: 进程数据段的大小(虚存),存放了初始化的数据
VmStack: 用户态栈大小
VmExe: 进程所拥有的可执行虚拟内存大小,代码段(不包括使用库),纯代码
Vm_Lib: 映射到进程的虚拟内存空间的库的大小
Vm_Rss: 进程所占用的实际的物理内存的大小
你会发现:
结合(4),(5)两个信息可以得到
(代码段的页数+数据/堆栈页数+引用库占用页数)*页大小=Vm_Rss
(6)查看进程的地址映射信息
cat /proc/pid/maps
可以看到所有虚拟地址空间的映射分布
综合这些信息,认为还是无法仅通过proc文件系统找出内存泄漏的具体位置
通过这次的分析和尝试可能印证了网上流传的说法:
linux 2.4的线程就是进程,只不过会出现两个号码,进程ID和线程ID,但是都代表了同一个东西
最后的解决方式是:
给出自己的内存管理Malloc,Free方式
这个方法就是对所有的内存的申请都维护一份指针的链表(采用内核链表)
释放时都就是对这个链表进行相应的删除操作就行了。
整个系统退出时,将这个链表进行逐个删除释放就行了
阅读(2725) | 评论(0) | 转发(0) |