首页 技术 正文
技术 2022年11月23日
0 收藏 591 点赞 2,193 浏览 4566 个字

  服务器上线之后,发生了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的时候表现出各种奇怪的样式。

微信扫一扫

支付宝扫一扫

本文网址:https://www.zhankr.net/141651.html

相关推荐
python开发_常用的python模块及安装方法
adodb:我们领导推荐的数据库连接组件bsddb3:BerkeleyDB的连接组件Cheetah-1.0:我比较喜欢这个版本的cheeta…
日期:2022-11-24 点赞:875 阅读:5,071
Educational Codeforces Round 11 C. Hard Process 二分
C. Hard Process题目连接:http://www.codeforces.com/contest/660/problem/CDes…
日期:2022-11-24 点赞:806 阅读:3,505
下载Ubuntn 17.04 内核源代码
zengkefu@server1:/usr/src$ uname -aLinux server1 4.10.0-19-generic #21…
日期:2022-11-24 点赞:565 阅读:4,316
可用Active Desktop Calendar V7.86 注册码序列号
可用Active Desktop Calendar V7.86 注册码序列号Name: www.greendown.cn Code: &nb…
日期:2022-11-24 点赞:730 阅读:4,311
Android调用系统相机、自定义相机、处理大图片
Android调用系统相机和自定义相机实例本博文主要是介绍了android上使用相机进行拍照并显示的两种方式,并且由于涉及到要把拍到的照片显…
日期:2022-11-24 点赞:512 阅读:4,911
Struts的使用
一、Struts2的获取  Struts的官方网站为:http://struts.apache.org/  下载完Struts2的jar包,…
日期:2022-11-24 点赞:671 阅读:3,099
发表评论
暂无评论

还没有评论呢,快来抢沙发~

助力内容变现

将您的收入提升到一个新的水平

点击联系客服

在线时间:8:00-16:00

客服电话

400-888-8888

客服邮箱

ceotheme@ceo.com

扫描二维码

关注微信公众号

扫描二维码

手机访问本站