嵌入式系统通过proc文件系统查内存泄漏发现行不通 应用程序, 基本原则, 嵌入式, 信息

苹果也疯狂

嵌入式系统中的应用程序库可能比较少，没有像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方式
这个方法就是对所有的内存的申请都维护一份指针的链表(采用内核链表)
释放时都就是对这个链表进行相应的删除操作就行了。
整个系统退出时，将这个链表进行逐个删除释放就行了