Core dump调试小记（暂时未解决）

缘起
现场的故障，让我支持一下。
过程
第一次

通过简易的日志，定位到了函数文件，远程连到现场环境，直接gdb进程名，一直到函数return，都没有core掉。
干得比较仓促，都没有再看看相关函数

第二次

吃完饭，睡过觉后，继续定位，毕竟现场的优先级高啊。

跟人沟通后，get到两点思路，让现场确认一下

1、看下.config的CLTSERVID的值和链路的值是不是不样，确认后都是26。
2、调高日志级别，原来是0（只显示错误的），让现场改成3，最高可支持9。这个后期得了解一下

第一次，我没有找到生成的core文件，也就没管，直接gdb了，后面就看了一下。

linux下生成core dump文件方法及设置

ulimit -c如果是0，则无法生成core dump，当然也可以用ulimit -a查看。用ulimit -c 2048去设置core的大小

让现场试了以上三招后，重新跑个进程，捞个日志来看看的，给我截图说这个错“ORA-00257: archiver error. Connect internal only, until freed ”，是现场的生产环境连接不上库了，于是再次挂起。

最后
参考

段错误调试神器 – Core Dump详解
关于ORA-00257: archiver error. Connect internal only, until freed 错误的处理方法

履历
20190212遇到的问题，写了第一次、第二次。