叮咚的博客

工作经验不是用你工作了几年来衡量的，哪怕你工作10年，但这10年你干的活内容是一样的，没有进取，那你的工作经验就是一年；以前奉行着在工作中成长，现在想法变成了在成长中工作；工作几年一直在寻找一个问题排查的专栏，想跳过自我总结这一步，直接拥有5-10年的工作经验，想要工作5年却有着别人10年的工作经验，但到目前为止遗憾也没能找到这么一个专栏，现在自己工作这么些年了，成长为公司专家，解决了很多问题，对自己的解决的问题做一个深挖、回忆、总结，同时也分享出来方便大家借鉴。

本文总结介绍了项目开发过程中oom排查和内存优化的一些方法，主要是从内存问题查看到堆内存、栈内存、数据段内存优化为导向，结合实际优化实例介绍工具和方法的运用，展示每种优化方法优化过程，希望对读者有所帮助。

gdb的基础和进阶命令，都是工作中最常用的，并且可以覆盖工作98%的使用

asan检测内存漏洞（堆踩内存、栈越界、堆越界、使用未初始化的内存等）和内存泄漏，如果不使用工具，我们直接去排查，那成本将是巨大的，我们曾经解决过野指针问题，公司专家六七个人，开会实现研究复现找规律，分析了两周才得以解决，如果使用asan，可能也就1天搞定。

本文主要介绍perf在嵌入设备，在真实工作产品化项目中，集成perf过程中遇到的问题和踩过的坑，指导你如何用perf来分析并解决CPU idle为0的问题。

valgrind 是一套 Linux 下，开放源代码的动态调试工具集合，能够检测内存管理错误、线程 BUG 等，valgrind 由内核（core）以及基于内核的其他调试工具组成。内核类似于一个框架（framework），它模拟了一个 CPU 环境，并提供服务给其他工具；而其他工具则类似于插件 (plug-in)，利用内核提供的服务完成各种特定的内存调试任务。Memcheck内存错误检测器：它有助于使你的程序，尤其是那些用C和C++写的程序，更加准确。

在嵌入式设备交叉编译strace，结合工作实际经验，总结了编译遇到的各种问题，并且在strace中集成了libunwind和libiberty用于支持-k参数打印堆栈和显示demangle符号；最后结合工作中项目实践经验分享了利用strace解决过的问题

在众多的coredump中，有一类crash调试起来是最麻烦的，那就是“栈被破坏”导致的函数调用回溯结构破坏引发的coredump。本文，主要讲讲这一类crash的成因、原理以及调试方法、如何还原堆栈并定位该问题

堆越界在实际工作开发中也属于一个比较常见的问题，一般死机的位置是被踩的，并不是第一现场，这种问题集成内存分析工具（asan）排查是比较方便的，但是在真实项目开发中，工程链接的库在上百个，每个库都去开启asan编译选项没那么方便，掌握直接排查堆越界问题的方法是很有必要的。 本文基于嵌入式linux平台，以一个堆越界的死机案例，讲述了如何只使用gdb分析core文件确定是哪里越界导致的程序死机。

C/C++开发的程序执行效率很高，但却经常受到内存泄漏的困扰。本文提供一种通过wrap malloc查找memory leak的思路，有静态链接和动态链接两种方法，依靠这个方法，解决了大量内存泄漏问题，该方法在日后工作中大放光彩，发现了项目中大量沉疴已久的内存泄漏问题。

透明大页（Transparent Huge Pages），RHEL 6 开始引入，目的是使用更大的内存页面（memory page size） 以适应越来越大的系统内存，让操作系统可以支持现代硬件架构的大页面容量功能。这里我先介绍一下遇到的问题，读者可以思考一下，遇到下面这个问题导致的oom，目前自己现有的知识是否可以解决。由于栈的内存是操作系统本身进行管理的，所以我们无法通过现成的工具来统计线程实际使用了多少物理内存，不过操作系统也提供了便捷的方式让我们可以查看线程栈内存，那就是smaps信息。

可执行程序中数据段的内存并不需要我们自己管理，在进程加载的时候系统自动为这些数据分配了内存，所以数据段的大小也作为我们内存优化时的一项，有必要对其进行分析。本文介绍一下数据段都存储的什么以及如何统计.rodata、.bss、.data中存储的变量的大小。

程序运行需要加载到内存中，代码段的大小直接影响到内存的使用，所以可以从代码段的角度来对内存进行优化；本文就分享一下如何统计可执行程序中链接的各个库代码段的大小。本文只介绍原理，如果链接的库比较少的话可以直接按照下面方法分析，大型项目中链接的库可能比较多，可以按照下面原理写脚本解析。

部分读者可能不关注详细分析过程，这里直接说明一下结论：setenv接口在设置环境变量时，可能会调用realloc来扩充存储环境变量的内存，由于realloc实现机制，realloc返回的地址有可能和我们传入待扩容的地址是不一样的；因为没有多线程异步保护，getenv访问到realloc已经释放的内存，导致死机。一般死机出现在getenv中则大概率是该原因导致的。总之程序运行之后，禁止再去修改环境变量，可能导致死机。

本文首先以一个案例描述了死机现场和死机的原因，然后介绍了运行时加载和直接动态链接的区别，并介绍了动态库加载函数dlopen、dlsym、dlerror函数的使用方法，特别是RTLD_NOW在dlopen检测所有符号是否链接，以及RTLD_NEXT在malloc重载定位内存泄漏的使用。

作为嵌入式软件开发工程师，开发调试过程中，遇到业务上的问题，基本不会往硬件方面考虑；特别是针对本文要描述的此类问题，开始一度怀疑是软件踩内存，排查到最后尽是ddr硬件焊接短路导致的地址索引异常。本文对该问题的排查思路作出分享，帮助读者积累一些经验。另外介绍了在分析过程中使用的内存测试工具memtester如何在嵌入式环境交叉编译执行。

为了杭州E类人才的优惠政策，开始准备高级系统架构师考试，历时3个月，做了一个总结和经验的分享，帮助有需要的人。

既然你能搜到这篇文章，说明你像过去的我一样遇到了迷茫期，不知道该何去何从，感觉人很迷茫、压抑，可能也学了很多东西，但是又感觉啥都不会一样；想进步、想提升但是也没有一个方向。分享一下我自己工作中的一些经验心得和针对这种迷茫期的一些想法.........

mprotect()函数可以修改调用进程内存页的保护属性，如果调用进程尝试以违反保护属性的方式访问该内存，则内核会发出一个SIGSEGV信号给该进程。函数介绍头文件：#include <sys/mman.h>函数定义：int mprotect(void *addr, size_t len, int prot);入参：addr：内存地址要求是一个内存页的首地址，简而言之为页大小（一般是 4KB == 4096字节）整数倍。len：被修改保护属性区域的长度，页大小整数倍。修改

【内存越界定位】MALLOC_CHECK_【内存越界定位】magic number待完成：glibc提供的malloc()的调试工具：https://www.cnblogs.com/arnoldlu/p/10827884.html

增加魔术，确认是越界还是已经释放的内存被非法重用。重写malloc函数，在malloc时头部多申请一些内存，存入0x12345678和当前线程号，在尾部也放入一个魔术；在free的时候检验魔数值，如果不是malloc的值就调用mprobe强制glibc对内存块进行完整性检查。在发生死机时，我们可以向前偏移，根据上一块内存的大小，确认malloc尾部的魔数是否被修改了，如果被修改表示上一块内存发生了越界访问，再根据线程号和大小找到前一块内存申请的位置进行代码分析；如果没被修改则应该是free之后使用内存.

GNU C Library可以根据环境变量MALLOC_CHECK_来决定是否在运行时可检测程序中的内存问题。但是只能检测malloc和free的问题；即便是越界了，也只能等下一次去malloc或者free的时候才能发现。因此只适用于free和malloc的这种死机问题定位。1、基础MALLOC_CHECK_有三种设定,即:MALLOC_CHECK_=0, 和没设置一样，将忽略这些错误MALLOC_CHECK_=1, 将打印一个错误告警MALLOC_CHECK_=2, 程序将收到SIGAB.