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遇到的问题，写了第一次、第二次。