当程序出错或者异常退出的时候，满足一定条件会产生coredump，并产生core文件，当然有时也不会生成，会提示coredump，这时我们需要对环境进行配置才会产生core文件。
首先我们需要通过ulimit敏玲查看core文件大小限制，需要生成core文件限制不能太小，所以我们一般都设置不限制
ulimit -a
查看到core file size是0，我们使用命令修改下
ulimit -c unlimited
再次使用ulimit命令查看就已经被改为unlimited了，除此之外还需要修改core_pattern文件
echo "/tmp/core-%e-%p-%s-%t" > /proc/sys/kernel/core_pattern
参数释义如下：
%p 出Core进程的PID %u 出Core进程的UID %s 造成Core的signal号 %t 出Core的时间，从1970-01-0100:00:00开始的秒数 %e 出Core进程对应的可执行文件名
在每个进程下都有coredump_filter节点/proc/pid/coredump_filter。
通过配置coredump_filter可以选择需在coredump的时候，将哪些内容dump到core文件中。
coredump产生的原因主要有以下几种情况
1、内存访问越界 2、多线程程序使用了线程不安全的函数。 3、多线程读写的数据未加锁保护。 4、非法指针 5、堆栈溢出
core文件包含了程序运行时内存、寄存器状态、堆栈指针、内存管理信息以及函数调用堆栈信息，我们通过分析core文件可以找到应用程序崩溃的地方。
上述是配置如何产生core文件，下面我就来看看如何使用gdb调试core文件进行问题分析的一些命令
gdb调试需要产生core文件原程序，命令如下：
gdb 源程序 core文件
| 命令 | 解释 |
|---|---|
| list/l | 查看程序 list +函数名称/行号 list 显示当前行后面的源程序 list -显示当前行前面的源程序 |
| run/r | 运行程序，设置运行参数 |
| help | 显示帮助信息 |
| start | 单步执行，运行程序，停在第一条执行语句 |
| break/b | break function在指定的函数停止 break 行号 在指定代码行打断 break +offset/break -offset在当前行的前面或后面的offset行打断点，offset为自然数 break 在下一条命令处停止运行 break … if < condition>如设置break if i=100表示当i为100时程序停止运行 |
| info | 查看信息 info break [n]其中n 表示断点号来查看断点信息 info signals info handle: 查看有哪些信号正在被gdb检测 |
| next < count> | 单步跟踪，如果有函数调用不会进入函数，如果后面不加count表示一条一条的执行，加count表示执行后面的count条指令 |
| step < count> | 单步跟踪，如果有函数调用则进入该函数（进入该函数前提是此函数编译有Debug信息）,与next类似，其不加count表示一条一条执行，加上count表示自当前行开始执行count条代码指令 |
| finish | 运行程序直到当前函数完成并打印函数返回时的堆栈地址和返回值及参数值等信息 |
| until | 运行程序直到退出循环体 |
| continue/c | 当程序遇到断点停止运行后可以使用continue命令恢复程序的运行到下一个断点或直到程序结束 |
| 查看变量 | |
| set | 设置变量的值 |
| s | 查看内存 格式x /nfu addr |
| watch | watch命令一般来观察某个表达式(变量也可视为一种表达式)的值是否发生了变化，如果由变化则程序立即停止运行 |
| return | 如果在函数中设置了调试断点，在断点后还有语句没有执行完，这个时候我们可以使用return命令强制函数忽略还没有执行的语句并返回。 |
| quit/q | 退出gdb调试 |
| whatis/ptype | 显示变量的类型 |
| bt | 显示函数调用路径 |