问题定位：内存泄漏，踩内存。

1.内存泄漏

    确定现象：

     linux 内存泄漏，可以查看slabinfo 和另外一个proc下（貌似meminfo），关于内存的信息，可以看到内存是否在不断减少，以及减少的速度。

    vxworks系统，内存是否有相关信息？？？

    如果快速泄漏内存，则较容易判断。如果是非常慢的，则要经过一定时间场景复现后，应该也能看出来。

    linux在内存耗光后，会有log打印。容易判断。vxworks待试验。

 

    在确认存在内存泄漏后，如何确认泄漏源头？

    malloc做修改，使其记录相关信息 ---- 当前是否此功能。没有就当没说。

    复现场景。在什么场景下会泄漏，具体点，哪个任务在跑是会泄漏，由此确认。

 

【 具体方法补充】

Linux在内存使用上的原则是：如果内存充足，不用白不用，尽量使用内存来缓存一些文件，从而加快进程的运行速度，而当内存不足时，会通过相应的内存回收策略收回cache内存，供进程使用。

可通过对proc下进程相关的文件进行分析，精确评估系统消耗内存的大小，还可以对内存泄露类问题的解决提供一种定位手段。

一、系统总内存的分析

可以从proc目录下的meminfo文件了解到当前系统内存的使用情况汇总，其中可用的物理内存=memfree+buffers+cached，当memfree不够时，内核会通过回写机制(pdflush线程)把cached和buffered内存回写到后备存储器，从而释放相关内存供进程使用，或者通过手动方式显式释放cache内存：

echo 3 > /proc/sys/vm/drop_caches

通过cat /proc/meminfo 查看内存使用情况。

　二、进程使用内存的统计

在32位操作系统中，每个进程拥有4G的虚拟内存空间，其中0~3GB是每个进程的私有用户空间，这个空间对系统中其他进程是不可见的。3~4GB是linux内核空间，由系统所有的进程以及内核所共享的。通过访问/proc/{pid}/下相关文件，可以了解每个线程虚拟内存空间的使用情况，从而了解每个线程所消耗内存的多少。

由于我们的产品都是使用多线程方式实现的，多个线程共享一个进程的用户态虚拟地址空间，虚拟地址空间包含若干区域，主要有如下几个区域：

1、当前执行文件的代码段，该代码段称为text段。

2、执行文件的数据段，主要存储执行文件用到的全局变量，静态变量。

3、存储全局变量和动态产生的数据的堆。

4、用于保存局部变量和实现函数调用的栈。

5、采用mmap方式映射到虚拟地址空间中的内存段

所以只需要查看任意一个线程的用户态虚拟地址空间分配即可知道属于同一进程的所有线程占用总内存的大小。可以通过查看/proc/{pid}/maps文件来获取相关的虚拟地址空间内容

如果在实际的调试过程中，怀疑某处发生了内存泄露，可以查看该进程的maps表，看进程的堆段或者mmap段的虚拟地址空间是否持续增加，如果是，说明很可能发生了内存泄露，如果mmap段虚拟地址空间持续增加，还可以看到各个段的虚拟地址空间的大小，从而可以确定是申请了多大的内存，对调试内存泄露类问题可以起到很好的定位作用。

 

 

2.踩内存。

    1）预先分配的内存被踩。比如共享内存，axi_mem。有可能是其他核或当前核的不同启动阶段。

        先确认分配是否有问题，分配空间是否重叠。如果在边界，则重点怀疑相邻区域。

    也可能公共IP资源的寄存器，被胡乱修改，如果在当前核未做写操作时，寄存器被改“写”，则应该是其他核干的。

    2）系统内部，一个核的系统运行，普通的内存。

       不好弄。可以尝试打条件断点。被踩后错误的值是多少，合理的值是多少。

        是不是被自己模块内的数组越界等原因所踩。

如果是因为为初始化指针访问，导致向随机地址上写，不用太担心，因为更大可能是data abort。

  

 用处不大。。