在brpc接口内部core，但是使用gdb分析时遇到问题

[adanteng]

#include <string>
std::stof("a");

在brpc接口内部使用该方法，导致服务core。通过分析core有办法能直接定位到哪一行出现的问题吗？

使用gdb打开core文件，bt后得到下面的信息：

(gdb) bt
#0  0x00007f98eb2b11f7 in raise () from /lib64/libc.so.6
#1  0x00007f98eb2b28e8 in abort () from /lib64/libc.so.6
#2  0x0000000000a7a6b5 in __gnu_cxx::__verbose_terminate_handler() ()
#3  0x0000000000a23406 in __cxxabiv1::__terminate(void (*)()) ()
#4  0x0000000000a7a159 in __cxa_call_terminate ()
#5  0x0000000000a232f4 in __gxx_personality_v0 ()
#6  0x0000000000a7eeb3 in _Unwind_RaiseException_Phase2 ()
#7  0x0000000000a7f6a7 in _Unwind_Resume ()
#8  0x00000000007bdd2a in operator() (this=<optimized out>, obj=<optimized out>) at ./src/brpc/destroyable.h:33
#9  ~unique_ptr (this=<synthetic pointer>, __in_chrg=<optimized out>) at /usr/include/c++/4.8.2/bits/unique_ptr.h:184
#10 ~DestroyingPtr (this=<synthetic pointer>, __in_chrg=<optimized out>) at ./src/brpc/destroyable.h:39
#11 brpc::policy::ProcessRpcRequest (msg_base=<optimized out>) at src/brpc/policy/baidu_rpc_protocol.cpp:508
#12 0x00000000008df7fa in brpc::ProcessInputMessage (void_arg=void_arg@entry=0x7f98a8021930) at src/brpc/input_messenger.cpp:132
#13 0x00000000008e07e4 in operator() (this=<optimized out>, last_msg=0x7f98a8021930) at src/brpc/input_messenger.cpp:138
#14 brpc::InputMessenger::OnNewMessages (m=0x7f987401ac80) at /usr/include/c++/4.8.2/bits/unique_ptr.h:184
#15 0x00000000008d04ed in brpc::Socket::ProcessEvent (arg=0x7f987401ac80) at src/brpc/socket.cpp:1049
#16 0x000000000071c1f4 in bthread::TaskGroup::task_runner (skip_remained=<optimized out>) at src/bthread/task_group.cpp:291
#17 0x0000000000834791 in bthread_make_fcontext ()
#18 0x0000000000000000 in ?? ()




[adanteng]

我用下面会引起core的代码试验了下：

+char *str;
+str = "GfG";
+*(str+1) = 'n';

会给出业务代码的位置。像stof这种throw std::invalid_argument异常的情况我在非brpc环境下也试验了一下。是可以正常提示具体core位置的。

[jamesge]

你可以跑下asan

[adanteng]

asan是内存监测工具，您的意思是stof这种，因为传入字符串导致的core，能监测出来？

我先用下试试

[jamesge]

如果你不知道为什么core，asan是帮助找出可能有内存问题的地方。如果你知道那句话铁定crash，但coredump显示位置不准，一般是开了优化的关系。

[adanteng]

我在下面的函数中，在CallMethod之前直接std::stof("a")，core文件中提示的位置和最上面代码段中的一致。

#11 brpc::policy::ProcessRpcRequest (msg_base=<optimized out>) at src/brpc/policy/baidu_rpc_protocol.cpp:508

所以，可能是编译brpc的时候，增加了优化项？

CXXFLAGS=$(CPPFLAGS) -O2 -g -rdynamic -pipe -Wall -W -fPIC -fstrict-aliasing -Wno-invalid-offsetof -Wno-unused-parameter -fno-omit-frame-pointer -std=c++0x

我尝试将 -O2 去掉，重新编译实验下

[adanteng]

不是O2的问题，增加-g，brpc内部函数调用的堆栈信息已经打印出来，可以调试。

不过brpc接口内部的业务代码 throw exception，导致服务core掉，这个core文件，bt后丢掉了业务代码的堆栈。这个问题是什么原因那？

[jamesge]

O2会影响bt的准确度

[adanteng]

我去掉了O2，但是rpc接口内部的函数调用栈确实是没有体现在core文件当中。这个事是为啥呢？

[jamesge]

这是不可能的，说明没有去全。

[adanteng]

只有下面的堆栈信息：

(gdb) bt
#0  0x00007fc23f2261f7 in raise () from /lib64/libc.so.6
#1  0x00007fc23f2278e8 in abort () from /lib64/libc.so.6
#2  0x00000000010e0235 in __gnu_cxx::__verbose_terminate_handler() ()
#3  0x0000000001089e56 in __cxxabiv1::__terminate(void (*)()) ()
#4  0x00000000010dfcd9 in __cxa_call_terminate ()
#5  0x0000000001089d44 in __gxx_personality_v0 ()
#6  0x00000000010e58e3 in _Unwind_RaiseException_Phase2 ()
#7  0x00000000010e60d7 in _Unwind_Resume ()
#8  0x0000000000da5d75 in brpc::policy::ProcessRpcRequest (msg_base=0x7fc208022700) at src/brpc/policy/baidu_rpc_protocol.cpp:508

如果是我自己非rpc服务，throw exception导致的core，core文件会明确指出哪里出问题

[adanteng]

brpc怎么修改Makefile，才能保证业务内部堆栈的输出呢？

[adanteng]

我也构造了segmentfault类型的错误在rpc的接口中，类似我之前说的：

+char *str;
+str = "GfG";
+*(str+1) = 'n';

这种报错，在core文件中，是有明确体现的，能直接定位问题的位置

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. 由于最近缺乏更新，这个issue已被自动标记为过期。如果接下来几天仍没有更新，它将会被关闭。感谢你的贡献。