core时看不到具体崩溃点的解决方法

1、如何在堆栈被破坏的情况下解决宕机问题（转的）

宕机不用怕，原来这样哒！
通常在生产环境下如果遇到宕机，我们的做法很简单gdb调试core文件，可以看到程序的堆栈信息，就可以定位问题，解决问题。
但是在某些情况下，堆栈信息由于某些原因被损坏了，bt打出来显示的全是??????
那么如果想找到问题那就难办了。
不过今天我们介绍一种，方法
使用GCC内建函数
__builtin_return_address(level)   
 level=0表示第一层地址
 level=1表示第二层地址
 level=2表示第三层地址
以此类推
使用时直接 
1. printf("address %p -%p -%p ", __builtin_return_address(0),__builtin_return_address(1),__builtin_return_address(2));




2. 反编译 objdump -Cd yourExecutable > my.asm
查看printf的输出
address 0x48161a -0x4928e8 -0x739e94
这样我们就知道上面那条语句的调用情况是
0x48161a
0x4928e8
0x739e94


在my.asm中找到对应的函数地址.
就找到了相应的函数名，ok，到这里大家都明白了。

2、共享库so有时候core的时候只能看到是so引起的core，找不到具体的函数：

 

可通过如下方法寻找 core 的函数信息：

1. 找到导致 core 的 rank 模块，在上面的例子中，rank 模块被重命名为 libSearcherRank.so_1534892175 了，在相应目录下找到原始的动态库；
2. 运行 objdump -Cd libSearcherRank.so > a.log
3. vim a.log  找到其中一个 frame 的地址， 比如 0x0x1e9f1c

从上面大约可以看见是 searcher_rank::P13NGenderRank::_Adjust 函数调用  boost::lexical_cast 引起的