从零开始学习MySQL调试跟踪（2）

可拉的叹息

• GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。
  
• GreatSQL是MySQL的国产分支版本，使用上与MySQL一致。
  
• 作者：  Yejinrong/叶金荣
  
• 文章来源：GreatSQL社区投稿
  

• 启用coredump
  
• 制造一个coredump场景
  
• 真实故障场景分析跟踪
  

上一篇文档介绍了如何构建gdb跟踪调试环境，本文介绍如何根据错误日志信息，跟踪定位问题可能的原因，以及如何利用coredump文件查找问题线索。
1. 启用coredump

程序运行过程中可能会异常终止或崩溃，OS会把程序挂掉时的内存状态记录下来，写入core文件，这就叫 coredump，通过gdb结合core文件可以方便地进行调试。
利用core文件中保留的异常堆栈文件，能够帮助研发同学更快定位问题。因此，如果某些故障断断续续会出现，建议阶段性开启coredump功能。
想要开启coredump，需要先修改OS层的几个设置：

1. $ ulimit -c unlimited
2. $ sysctl -w fs.suid_dumpable=2
3. $ echo "core.%p.%e.%s" > /proc/sys/kernel/core_pattern

复制代码

同时，将这些修改持久化到相应文件中（假定MySQL/GreatSQL服务进程的属主用户是  mysql）：

1. $ echo "mysql  -  core   unlimited" >> /etc/security/limits.conf
2. $ echo "fs.suid_dumpable=2" >> /etc/sysctl.conf
3. $ echo "kernel.core_pattern=core.%e.%p.%t" >> /etc/sysctl.conf
4. $ sysctl -p

复制代码

接下来，修改 my.cnf 配置文件，增加以下两行内容：

1. core_file
2. innodb_buffer_pool_in_core_file=OFF

复制代码

然后重启GreatSQL服务进程，即可生效，查询确认下：

1. mysql> show global variables like '%core%';
2. +---------------------------------+-------+
3. | Variable_name                   | Value |
4. +---------------------------------+-------+
5. | core_file                       | ON    |
6. | innodb_buffer_pool_in_core_file | OFF   |
7. +---------------------------------+-------+

复制代码

这样设置完成后，需要的话会在 datadir 目录下生成core文件。
2. 制造一个coredump场景

我们可以给mysqld进程发送 SIGSEGV(11) 信号，即可模拟出coredump的场景，例如：

1. $ kill -s SIGSEGV `pidof mysqld`

复制代码

这时查看GreatSQL错误日志文件，以及core文件，就会发现有coredump：

1. $ls -la
2. ...
3. -rw-------   1 mysql mysql 1081147392 Feb 20 22:36 core.mysqld-debug.2658134.1676903816
4. ...
6. $ less error.log
7. ...
8. 14:36:56 UTC - mysqld got signal 11 ;
9. Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
11. Build ID: 1f4232b893100742b7c519df2fa714648c2d76d9
12. Server Version: 8.0.25-16-debug Source distribution
14. Thread pointer: 0x0
15. Attempting backtrace. You can use the following information to find out
16. where mysqld died. If you see no messages after this, something went
17. terribly wrong...
18. stack_bottom = 0 thread_stack 0x80000
19. /usr/local/GreatSQL-8.0.25-16-Linux-glibc2.28-x86_64/bin/mysqld-debug(my_print_stacktrace(unsigned char const*, unsigned long)+0x43) [0x4b04
20. d26]
21. /usr/local/GreatSQL-8.0.25-16-Linux-glibc2.28-x86_64/bin/mysqld-debug(handle_fatal_signal+0x2cb) [0x39a7d22]
22. /lib64/libpthread.so.0(+0x12c20) [0x7fc3e669ac20]
23. /lib64/libc.so.6(__poll+0x51) [0x7fc3e45c4a41]
24. /usr/local/GreatSQL-8.0.25-16-Linux-glibc2.28-x86_64/bin/mysqld-debug(Mysqld_socket_listener::listen_for_connection_event()+0x57) [0x3995195
25. ]
26. /usr/local/GreatSQL-8.0.25-16-Linux-glibc2.28-x86_64/bin/mysqld-debug(Connection_acceptor<Mysqld_socket_listener>::connection_event_loop()+0
27. x30) [0x355a024]
28. /usr/local/GreatSQL-8.0.25-16-Linux-glibc2.28-x86_64/bin/mysqld-debug(mysqld_main(int, char**)+0x27d2) [0x354e4a6]
29. /usr/local/GreatSQL-8.0.25-16-Linux-glibc2.28-x86_64/bin/mysqld-debug(main+0x20) [0x32de906]
30. /lib64/libc.so.6(__libc_start_main+0xf3) [0x7fc3e44f6493]
31. /usr/local/GreatSQL-8.0.25-16-Linux-glibc2.28-x86_64/bin/mysqld-debug(_start+0x2e) [0x32de82e]
32. Please help us make Percona Server better by reporting any
33. bugs at https://bugs.percona.com/
34. ...

复制代码

在一线的同学，如果需要向研发寻求支持或报告故障时，可以先参考这篇文章 MySQL报障之coredump收集处理流程，需要采集其他几个信息：

• 故障时刻的error log。
  
• 故障产生的core文件。
  
• 如果有general log的话，也采集起来（故障时刻往前约1小时或10万行日志）。
  
• 导致core发生涉及到的表DDL以及相应的SQL语句，有必要的话，可能还要同时提供真实数据（或样例数据）。
  

3. 真实故障场景分析跟踪

在GreatSQL 8.0.25-15版本（上一个版本）中，InnoDB并行查询功能在特定场景下存在bug，会导致crash，相应的日志见下：
[code]mysqld-debug: /opt/greatsql-8.0.25/sql/item.cc:6047: virtual void Item_field::make_field(Send_field*): Assertion `item_name.is_set()' failed.01:59:20 UTC - mysqld got signal 6 ;Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.Build ID: 1f4232b893100742b7c519df2fa714648c2d76d9Server Version: 8.0.25-debug Source distributionThread pointer: 0x7fb4a9a0b000Attempting backtrace. You can use the following information to find outwhere mysqld died. If you see no messages after this, something wentterribly wrong...stack_bottom = 7fb4f7aa53b0 thread_stack 0x80000/usr/local/GreatSQL-8.0.25-Linux-glibc2.28-x86_64/bin/mysqld-debug(my_print_stacktrace(unsigned char const*, unsigned long)+0x43) [0x4b04d26]/usr/local/GreatSQL-8.0.25-Linux-glibc2.28-x86_64/bin/mysqld-debug(handle_fatal_signal+0x2cb) [0x39a7d22]/lib64/libpthread.so.0(+0x12c20) [0x7fb5146cac20]/lib64/libc.so.6(gsignal+0x10f) [0x7fb51253a37f]/lib64/libc.so.6(abort+0x127) [0x7fb512524db5]/lib64/libc.so.6(+0x21c89) [0x7fb512524c89]/lib64/libc.so.6(+0x2fa76) [0x7fb512532a76]  #