目录
🍅点击这里查看所有博文
随着自己工作的进行，接触到的技术栈也越来越多。给我一个很直观的感受就是，某一项技术/经验在刚开始接触的时候都记得很清楚。往往过了几个月都会忘记的差不多了，只有经常会用到的东西才有可能真正记下来。存在很多在特殊情况下有一点用处的技巧，用的不多的技巧可能一个星期就忘了。
想了很久想通过一些手段把这些事情记录下来。也尝试过在书上记笔记，这也只是一时的，书不在手边的时候那些笔记就和没记一样，不是很方便。
很多时候我们遇到了问题，一般情况下都是选择在搜索引擎检索相关内容，这样来的也更快一点，除非真的找不到才会去选择翻书。后来就想到了写博客，博客作为自己的一个笔记平台倒是挺合适的。随时可以查阅，不用随身携带。
同时由于写博客是对外的，既然是对外的就不能随便写，任何人都可以看到。经验对于我来说那就只是经验而已，公布出来说不一定我的一些经验可以帮助到其他的人。遇到和我相同问题时可以少走一些弯路。
既然决定了要写博客，那就只能认真去写。不管写的好不好，尽力就行。千里之行始于足下，一步一个脚印，慢慢来 ，写的多了慢慢也会变好的。权当是记录自己的成长的一个过程，等到以后再往回看时，就会发现自己以前原来这么菜😂。
本系列博客所述资料均来自互联网，并不是本人原创（只有博客是自己写的）。出于热心，本人将自己的所学笔记整理并推出相对应的使用教程，方面其他人学习。为国内的物联网事业发展尽自己的一份绵薄之力，没有为自己谋取私利的想法。若出现侵权现象，请告知本人，本人会立即停止更新，并删除相应的文章和代码。
什么是CoreDump
Linux系统下存在一种异常时内存转储的机制。当程序在运行过程中发生严重错误或异常时，操作系统将程序当前的内存状态以及相关信息保存到一个文件中的过程，这个文件通常被称为core文件。这种机制被称为CoreDump转储。CoreDump分析是Linux 开发中经常使用的方法。
CoreDump的作用
通过分析CoreDump文件，开发人员可以更好地理解程序运行时的状态，从而提高程序的稳定性和可靠性。CoreDump文件是开发人员调试程序时的重要工具，能够帮助他们快速定位和解决程序中的问题，提高开发效率。
CoreDump的作用主要包括如下几点：
- 调试和分析： 提供了程序崩溃时的内存快照，可以帮助开发人员定位问题，重现崩溃场景，并进行调试和分析。
- 恢复数据： 有时程序崩溃可能导致数据丢失，CoreDump可以保存程序崩溃时的内存状态，使得可以尝试从中恢复一些关键数据。
- 追踪程序状态： 可以查看程序崩溃时的堆栈信息、变量值等，帮助理解程序运行时的状态。
- 优化性能： 通过分析CoreDump，可以了解程序在崩溃前的运行状态，有助于发现潜在的性能问题并进行优化。
CoreDump包含什么内容
其输出的core文件是一个ELF格式的内存镜像文件，主要用来调试，没法以文本的方式打开，通常会在指定目录下生成。
root@kvm:~/CoreDump# file ./core
./core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './TestCoreDump'
CoreDump包含了进程在崩溃或异常终止时的内存映像，其中包括程序的数据、堆栈和寄存器状态等信息。这个内存映像可以帮助开发人员调试程序并找出导致崩溃的原因。
开发人员可以使用GDB（GNU调试器）来分析CoreDump文件。在GDB中，您可以使用bt命令来打印堆栈跟踪信息，info registers命令来查看寄存器状态，以及其他命令来检查变量值等。根据这些手段从而找出程序崩溃的具体原因，并进行修复。
(gdb) bt
#0 0x00007f6a84cdf438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007f6a84ce103a in __GI_abort () at abort.c:89
#2 0x00007f6a84d217fa in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f6a84e3af98 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007f6a84d2e6e8 in malloc_printerr (ar_ptr=0x0, ptr=<optimized out>, str=0x7f6a84e3afc0 "munmap_chunk(): invalid pointer", action=<optimized out>) at malloc.c:5020
#4 munmap_chunk (p=<optimized out>) at malloc.c:2849
#5 __GI___libc_free (mem=<optimized out>) at malloc.c:2970
#6 0x0000000000400542 in dumpCrash () at TestCoreDump.c:6
#7 0x0000000000400553 in main () at TestCoreDump.c:11
除了GDB外，还有一些工具可用于分析CoreDump，如valgrind、lldb等。这些工具可以帮助您更好地理解导致程序崩溃的原因，以及如何修复问题。
什么时候需要CoreDump
CoreDump通常在程序发生严重错误（如段错误、非法指令等）导致崩溃时生成，有助于开发人员调试程序并了解问题的根本原因。
下表列出了一些日常开发中可能会触发CoreDump的异常原因。当出现这些错误时，程序会终止运行。此时，我们需要通过CoreDump来明确问题的根本原因。
| 异常 | 说明 | 可能情况 |
|---|---|---|
| SIGABRT | 异常终止（abort） | free没有初始化的地址或者错误的地址 堆越界 assert |
| SIGBUS | 硬件故障 | 文件映射访问异常 访问不对齐的内存 内存访问异常 |
| SIGEMT | 硬件故障 | |
| SIGFPE | 算术异常 | 除以0 浮点溢出 |
| SIGILL | 非法硬件指令 | 执行一条非法硬件指令 |
| SIGIOT | 硬件故障 | |
| SIGQUIT | 终端退出符 | 终端上按退出键 |
| SIGSEGV | 无效存储访问 | 进行了一次无效的存储访问 |
| SIGSYS | 无效系统调用 | 进行了一次无效的系统调用 |
| SIGTRAP | 硬件故障 | |
| SIGXCPU | 超过CPU限制（setrlimit） | 进程超过了其软CPU时间限制 |
| SIGXFSZ | 超过文件长度限制（setrlimit） | 进程超过了其软文件长度限制 |
当然我们日常开发最长遇到的错误就是段错误，其他的错误就很少见了。段错误（Segmentation Fault）可能出现在以下情况：
- 对未分配内存进行读写操作。
- 对只读内存进行写操作。
- 空指针引用。
- 数组越界访问。
- 使用野指针。
- 在栈溢出时。
- 在多线程环境下出现竞争条件导致的问题。
那么本篇博客就到此结束了，这里只是记录了一些我个人的学习笔记，其中存在大量我自己的理解。文中所述不一定是完全正确的，可能有的地方我自己也理解错了。如果有些错的地方，欢迎大家批评指正。如有问题直接在对应的博客评论区指出即可，不需要私聊我。我们交流的内容留下来也有助于其他人查看，说不一定也有其他人遇到了同样的问题呢😂。
 mac＆win)
