内存的crash记录分析

　　服务器上线之后，发生了3次crash，感觉是一次比较典型的内存bug的排错经历，所以特地记录下来供以后借鉴。下面描述一下3次crash时候的coredump的当前堆栈信息。

　　第一次crash的coredump文件：

#0  0x00007f6f02d845f7 in raise () from /lib64/libc.so.6
#1  0x00007f6f02d85ce8 in abort () from /lib64/libc.so.6
#2  0x00007f6f02dc4317 in __libc_message () from /lib64/libc.so.6
#3  0x00007f6f02dcd86d in _int_malloc () from /lib64/libc.so.6
#4  0x00007f6f02dce8dc in malloc () from /lib64/libc.so.6
#5  0x00007f6f038a30cd in operator new(unsigned long) () from /lib64/libstdc++.so.6
#6  0x00007f6f03901c69 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) () from /lib64/libstdc++.so.6
#7  0x00007f6f03903521 in char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) () from /lib64/libstdc++.so.6
#8  0x00007f6f03903958 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /lib64/libstdc++.so.6
#9  0x00000000004b8880 in DataMng::WritePlayerBaseData(slither::PBPlayerBase const&) ()

　　从堆栈信息可以看出来，是逻辑一个函数在构造string对象的时候，最后在malloc的时候crash了，也就是_int_malloc这里开始。

　　第二次的coredump文件：

#0  0x00007f381f9ffa1d in malloc_consolidate () from /lib64/libc.so.6
#1  0x00007f381fa01ea5 in _int_malloc () from /lib64/libc.so.6
#2  0x00007f381fa038dc in malloc () from /lib64/libc.so.6
#3  0x00007f38207f2845 in my_malloc (size=size@entry=8160, my_flags=my_flags@entry=1040) at /export/home3/pb2/build/sb_0-19016729-1464156289.52/rpm/BUILD/mysql-5.7.13/mysql-5.6.25/mysys/my_malloc.c:38
#4  0x00007f38207f0cfc in alloc_root (mem_root=mem_root@entry=0x1a40c30, length=length@entry=24) at /export/home3/pb2/build/sb_0-19016729-1464156289.52/rpm/BUILD/mysql-5.7.13/mysql-5.6.25/mysys/my_alloc.c:224
#5  0x00007f38207c1e78 in cli_read_rows (mysql=mysql@entry=0x1a0d960, mysql_fields=mysql_fields@entry=0x0, fields=7) at /export/home3/pb2/build/sb_0-19016729-1464156289.52/rpm/BUILD/mysql-5.7.13/mysql-5.6.25/sql-common/client.c:1544
#6  0x00007f38207c306d in cli_read_query_result (mysql=0x1a0d960) at /export/home3/pb2/build/sb_0-19016729-1464156289.52/rpm/BUILD/mysql-5.7.13/mysql-5.6.25/sql-common/client.c:4144
#7  0x00007f38207c48f6 in mysql_real_query (mysql=0x1a0d960, query=<optimized out>, length=<optimized out>) at /export/home3/pb2/build/sb_0-19016729-1464156289.52/rpm/BUILD/mysql-5.7.13/mysql-5.6.25/sql-common/client.c:4181
#8  0x00000000004f90b3 in cputil::CMysqlConnection::Execute(char const*, cputil::CRecordSet&) ()
#9  0x00000000004b731b in DataMng::FindPlayerBaseInfoByPlayerId(unsigned long, slither::PBPlayerBase*) ()

　　第二次core文件，其实还是在malloc的时候crash了。　　

　　第三次的coredump文件：

#0  0x00007f48bc609d28 in _int_free () from /lib64/libc.so.6
#1  0x00000000004f49a1 in cpnet::Connection::HandleSend(boost::system::error_code const&, unsigned long) ()
#2  0x00000000004f7197 in boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::const_buffers_1, boost::asio::detail::transfer_all_t, boost::_bi::bind_t<void, boost::_mfi::mf2<void, cpnet::Connection, boost::system::error_code const&, unsigned long>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<cpnet::Connection> >, boost::arg<1> (*)(), boost::arg<2> (*)()> > >::operator()(boost::system::error_code const&, unsigned long, int) ()
#3  0x00000000004f74ff in boost::asio::detail::reactive_socket_send_op<boost::asio::const_buffers_1, boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::const_buffers_1, boost::asio::detail::transfer_all_t, boost::_bi::bind_t<void, boost::_mfi::mf2<void, cpnet::Connection, boost::system::error_code const&, unsigned long>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<cpnet::Connection> >, boost::arg<1> (*)(), boost::arg<2> (*)()> > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#4  0x00000000004e8f90 in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
#5  0x00000000004eab85 in boost::asio::io_service::run() ()

　　第三次的core，是在free的时候，也就是释放内存的时候crash了，从三次的堆栈上看，都是跟内存有关的bug。

　　第一次的异常很快就解决了，因为在做mysql_escape_string的时候没有为escape之后的buf申请更多空间，而是使用了跟原来一样的空间大小，导致内存冲突了。

　　剩下的另外2次coredump就比较有意思了，从逻辑角度是没有任何问题的，而且也可以保证没有线程问题，一次是因为_int_malloc也就是分配内存的时候crash了，而且是调用mysql api的时候，mysql的对象状态也是正常的。另外一条是网路层处理消息队列进行发送的时候，然后在_int_free_的时候报错的，_int_free_报错一般是由于重复释放内存，可以肯定函数里面没有手动释放内存的地方，唯一有一个队列pop了一下string对象。

　　联想到第一次的coredump，我怀疑是由于某种情况下内存溢出，或者错误，影响到了后面操作使用到的内存地址，然后后续操作在碰巧遇到这个地址相关操作的时候，就会crash了。具体是否是这样的，现在还没有办法验证，需要版本更新之后运行一段时间来看看修改后的稳定性。

　　经过修改后，一段时候之后再也没有出现过crash，可以基本确定，所有的问题都是同一个问题，只是因为内存一旦错乱之后，在crash的时候表现出各种奇怪的样式。