Linux 下 Segmentation fault (core dumped)调试-core文件

最近遇到一个app异常退出的bug，App log中有做好的 gdb_crash log (gdb_crash_pbshell_2022-03-0312_36_54)，可以显示函数调用栈和错误信息

Core was generated by `./pbshell mfg’.
Program terminated with signal SIGSEGV, Segmentation fault.

说明app异常退出时发生了段错误，访问空指针导致的（系统收到SIGSEGV信号时，杀死当前进程）。网上搜了“Program terminated with signal SIGSEGV, Segmentation fault.”，发现Linux下程序发生段错误会自动生成core文件。（当前的gdb_crash_pbshell_2022-03-0312_36_54.txt 应该就是core文件）。
以前不知道程序crash还会有core文件产生， 于是就想研究一下core文件是怎么产生的，里面都有什么内容，以及如何使用它。

1. 默认情况下，core文件会在当前可执行程序所在路径产生。

例如：
写一个会产生段错误的demo （路径: ~/workspace/demo）:

include<iostream>
  
int main()
{
        int * p=NULL;
        *p=1;
        return 1;
}

编译: g++ -g test.cpp
执行: ./a.out
报错: Segmentation fault(core dumped).
查看当前目录，发现多了一个core文件。

2.拿到core文件后怎么查看调用栈：

执行：gdb a.out core

3. 问题

crash时候，不产生core文件。
解决：
首先考虑系统限制问题
shell输入 ulimit -a
查看core文件有没有限制大小，发现没有，是unlimited，所以不是这个原因
（如果大小为0，说明禁止了core文件的产生，可以通过 ulimit -c unlimited 来解除限制）

其次考虑是不是程序实现和权限方面的问题
查阅资料，总结不产生core的相关情况如下：

程序设置了用户id（即调用setuid），但当前用户并非该程序文件的所有者
程序设置了组id(即调用setgid)，但当前用户并非该程序文件的组所有者
用户没有当前目录或指定core文件产生目录的写权限
core文件太大，磁盘空间不足
但以上并没有解决我的问题

其次考虑core文件产生位置
core的默认位置是程序所在目录，可以通过修改 /proc/sys/kernel/core_pattern 来指定core文件生成位置。
通过查看core_pattern文件，发现其确实指定了一个路径，

于是我前往那个路径，发现竟然是可执行程序，后来查看说明文件，才知道core_pattern中如果首先指定了一个 ‘|’ 管道符，则会将生成的core文件传递给后面所跟的脚本去处理。
至此，也就确定了问题的原因，| 管道符后面的脚本将我们的core文件给吞了，解决方法自然就是去掉这个脚本，换成自己指定的目录
但直接去修改core_pattern文件并没有成功，保存时会提示FSync错误，查阅资料得知，这个文件有特殊限制，只能通过命令:
sudo bash -c "echo 这里是写入内容 > /proc/sys/kernel/core_pattern "
我使用：

sudo bash -c "echo core > /proc/sys/kernel/core_pattern "

来进行写入，即指定程序所在目录为core文件生成目录，core文件名称为"core"。

之后再运行程序，core dump后，即在当前程序文件目录下生成了core文件