最近一个很讨厌的问题,mysql总是coredump,信息如下:

hellocdok 2010-01-04 11:16:17
每次提示信息都差不多如下:
#0 0xb58897a8 in strcmp () from /lib/libc.so.6
#1 0xb7fcc601 in array_append_string_unique () from/usr/lib/libmysqlclient_r.so.16
#2 0xb7fcebe8 in init_default_directories_unix () from/usr/lib/libmysqlclient_r.so.16
#3 0xb80202f4 in THR_LOCK_heap () from /usr/lib/libmysqlclient_r.so.16
#4 0x00000007 in ?? ()
#5 0xb7ff2354 in ?? () from /usr/lib/libmysqlclient_r.so.16
#6 0x00000200 in ?? ()
#7 0x00000000 in ?? ()
--
几个问号也显示不出来具体的代码是在哪里,单步跟踪很困难.
谁见过类似的问题?请高手帮忙看看
...全文
260 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
netxuning 2010-01-05
  • 打赏
  • 举报
回复
运行configure脚本的时候加上 --with-debug=full选项
hellocdok 2010-01-05
  • 打赏
  • 举报
回复
肯定是遭遇空指针了,程序里面用到的mysql函数也就那几个常用的,像mysql_fetch_row/mysql_real_query/mysql_free_result/mysql_store_result/等等.
另外mysql_free_result的处理也是没有重复的地方.
什么函数会调用THR_LOCK_heap()???
出现coredump的时间不固定,有时刚启动自己写的程序就有,有时一天一次,有时几天一次;
hellocdok 2010-01-05
  • 打赏
  • 举报
回复
错误日志里面相关的信息只有:
segfault at 0 ip b598f3a8 sp bff969bc error 4 in libc-2.3.6.so[b5927000+116000]
其它的没有了.
另外netxuning哥们说的'--with-debug=full',加上后会有什么现象,会不会造成mysql效率下降?
markshao 2010-01-04
  • 打赏
  • 举报
回复
错误日志拿出来看看把,正好学习一下
军爷_010 2010-01-04
  • 打赏
  • 举报
回复
把错误日志也输出来看看
军爷_010 2010-01-04
  • 打赏
  • 举报
回复
还有更多的信息了吗,这些还看不出来,/var/log/下看一下messages有没有提示更多的信息!

56,679

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧