Loading... # 第二集 水平不够导致的各种莫名segmentation fault 段错误就是指访问的内存超出了系统所给这个程序的内存空间。 描述很简单，但是以我非常有限的知识来看，成因太多，定位太难！！！ 曾尝试各种自动定位的方法，由于找不到 addr2line这样一个关键的目标平台工具，只能人工添加log一行一行进行排查定位，我是一只行走在寻找 segmentation fault 的“猪”，马不停蹄，鸟不停飞，最终我变为了一只瘦肉“猪”！ 以下是目前遇到的C开发过程中，遇到的各种crash。 * **空指针（访问不存在的内存地址）** 指针定义后，未被赋值，就引用，crash！ * **NULL指针（系统保护的内存地址）** 指针定义后，赋值为0或者NULL，目标为系统保护的内存地址，crash！ * **内存越限（数组超下标）** * **访问释放了的指针** * **玄学式** 增加几行log输出，就不再crash！ ...（后续补充）... 实际上，每次segmentation fault定位耗时远远超过coding时间，在经历了无限次的怀疑人生后，立志要寻找一种办法，起码方便调试。 * 于是乎，第一集的内容，继续上演。 * 于是乎，各种跨平台大型库：boost、folly等进入硬盘开启了吃灰之旅。 * 于是乎，各种所需第三方库，编译到各平台，开启了作死之旅： * CPU指令架构：arm、arm64、x86_64、x86、x64... * 项目文件组织：cmake、makefile * 项目文件包含：如何在构建文件中，描述文件包含（include和lib） * 静态库和动态库：static、share。特别记录：静态库不需要导入、导出声明！！！！ * 于是乎，能找到个head-only实现的第三方库时，我内心的喜悦，难以言表！ --- 经历太多次反复折腾，死在编译、构建上以后，目前编辑、调试、构建环境如下： **开发语言**：c++ 11，很可能会跳到 c++ 14 或者c++17上去，是否变更选择，取决于是否必须其语言特性。 **编辑**：windows 10 操作系统，vs code 使用ssh插件远程连接ubuntu虚拟机开展coding。 **调试**：构建基于虚拟机的应用程序，使用gdb在虚拟机完成调试，和bug查找工作。 **构建**：测试完成后，在ubuntu虚拟机上使用交叉编译工具，编译到目标平台。 最后修改：2021 年 03 月 26 日 06 : 42 PM © 允许规范转载