GreatSQL的sp中添加新的sp_instr引入的bug解析

海与鱼

GreatSQL的sp中添加新的sp_instr引入的bug解析

一、问题发现

在一次开发中用到的sp需要添加新的sp_instr以满足需求，但是添加了数个sp_instr以后发现执行新的sp会发生core。

注：本次使用的GreatSQL 8.0.32-25

1、sp_head.cc的init_sp_psi_keys()代码里面添加10个新的sp_instr：

1. void init_sp_psi_keys() {
2.   mysql_statement_register(category, &sp_instr_stmt1::psi_info, 1);
3.   mysql_statement_register(category, &sp_instr_stmt2::psi_info, 1);
4.   mysql_statement_register(category, &sp_instr_stmt3::psi_info, 1);
5.   ......
6.   mysql_statement_register(category, &sp_instr_stmt10::psi_info, 1);
7. }

复制代码

2、sp_instr.cc里面添加新的sp_instr_stmt相关实现代码，其中sql_yacc.yy和sql_lex.cc需要相应添加新的语法。
3、sp_rcontext.h处在·class sp_rcontext里面添加几个新的成员变量。下面代码只是示例，不具有实际使用价值。

1.   Field *m_return_value_fld_tmp{m_return_value_fld};
2.   Field *m_return_value_fld_tmp1{m_return_value_fld};
3.   Field *m_return_value_fld_tmp2{m_return_value_fld};

复制代码

4、创建新的sp，里面包含新的sp_instr_stmt的内容，然后call该sp，结果发现代码逻辑处因为一个list里面member的值被清空了，然后导致crash。下面是相关的堆栈。因为涉及代码机密，只截图开源部分相关堆栈。

1. #0  0x0000555558f3f3d9 in base_list_iterator::next_fast (this=0x7fffe01e9de0)
2.     at /sql/sql_list.h:371
3. #1  0x0000555558fc59b7 in List_iterator_fast<Create_field>::operator++ (this=0x7fffe01e9de0)
4.     at /sql/sql_list.h:605
5. #2  0x0000555559753ea2 in create_tmp_table_from_fields (thd=0x7fff20001050, field_list=...,
6.     is_virtual=false, select_options=0, alias=0x0)
7.     at /sql/sql_tmp_table.cc:2131
8. #3  0x0000555559084a09 in Item_xx::val_str (this=0x7fff20b673c8)
9.     at /sql/item_func.cc:10796
10. #4  0x0000555558fa408b in Item::save_in_field_inner (this=0x7fff20b673c8, field=0x7fff20b9b1a8,
11.     no_conversions=false) at /sql/item.cc:8202
12. #5  0x0000555558fa3c43 in Item::save_in_field (this=0x7fff20b673c8, field=0x7fff20b9b1a8,
13.     no_conversions=false) at /sql/item.cc:8144
14. #6  0x0000555559400322 in sp_eval_expr (thd=0x7fff20001050, result_field=0x7fff20b9b1a8,
15.     expr_item_ptr=0x7fff20b67620) at /sql/sp.cc:3613
16. #7  0x000055555943b1d1 in sp_rcontext::set_variable (this=0x7fff20b85d80, thd=0x7fff20001050,
17.     field=0x7fff20b9b1a8, value=0x7fff20b67620)
18.     at /sql/sp_rcontext.cc:1023
19. #8  0x0000555558fc3a8e in sp_rcontext::set_variable (this=0x7fff20b85d80, thd=0x7fff20001050,
20.     var_idx=1, value=0x7fff20b67620)
21.     at /sql/sp_rcontext.h:176
22. 打印crash处的信息，发现list里面的值被清空了。
23. (gdb) p tmp
24. $1 = (list_node *) 0x0

复制代码

二、问题调查过程

1、仔细检查代码发现代码逻辑没有问题，list的值确实都有成功赋值，但是运行时候却发现list被清空，显然这是别的地方内存泄漏或者内存溢出导致list的元素空间被占用了或者被清空了。把sp的代码换成别的，有时候会crash有时候不会crash，触发机制也不明朗，不知道具体哪句代码导致的内存泄漏。
2、于是回头继续看刚开始添加代码的地方，猜想是不是跟我添加了10个sp_instr_stmt有关，因为相关的数组或者内存没有添加扩容，很有可能因为这个导致内存溢出。
3、定位出疑似问题地方，就可以着手开始调查相关代码了。查看相关添加sp_instr的代码。

1. 添加sp_instr实现代码如下：
2. mysql_statement_register(category, &sp_instr_stmt1::psi_info, 1);
4. 于是继续往下面调查mysql_statement_register实现的代码，看到这里果然用到了statement_class_max：
5. PFS_statement_key register_statement_class(const char *name, uint name_length,
6.                                            PSI_statement_info *info) {
7.   /* See comments in register_mutex_class */
8.   uint32 index;
9.   PFS_statement_class *entry;
11.   REGISTER_CLASS_BODY_PART(index, statement_class_array, statement_class_max,
12.                            name, name_length)
14. 接着查看statement_class_max的赋值的地方：
15. int init_statement_class(uint statement_class_sizing) {
16.   int result = 0;
17.   statement_class_dirty_count = statement_class_allocated_count = 0;
18.   statement_class_max = statement_class_sizing;
20. 通过搜索代码查到statement_class_sizing相关的参数配置的地方，看到这里有一个SP_PSI_STATEMENT_INFO_COUNT宏定义，这个值跟sp_instr的数量有关。
21. static Sys_var_ulong Sys_pfs_max_statement_classes(
22.     "performance_schema_max_statement_classes",
23.     "Maximum number of statement instruments.",
24.     READ_ONLY GLOBAL_VAR(pfs_param.m_statement_class_sizing),
25.     CMD_LINE(REQUIRED_ARG), VALID_RANGE(0, 256),
26.     DEFAULT((ulong)SQLCOM_END + (ulong)COM_END + 5 +
27.             SP_PSI_STATEMENT_INFO_COUNT + CLONE_PSI_STATEMENT_COUNT),
28.     BLOCK_SIZE(1), PFS_TRAILING_PROPERTIES);
30. 继续全文搜索，发现在sp_head.h定义了，这里的值为16，数了一下现存的sp_instr个数刚好为16个，至此问题原因发现，因为我加了10个sp_instr，而这个宏定义的值没有跟着增加，导致内存溢出。
31. #define SP_PSI_STATEMENT_INFO_COUNT 16

复制代码

三、问题解决方案

通过以上代码解析后，就可以修改相关问题代码，只要作如下修改即可。重新编译完，问题解决。

1. sp_head.h修改SP_PSI_STATEMENT_INFO_COUNT宏定义：
2. #define SP_PSI_STATEMENT_INFO_COUNT 26
4. 因为增加了Sys_pfs_max_statement_classes的default值，因为相关配置范围也要跟着增加，因此把range相应加大。
5. static Sys_var_ulong Sys_pfs_max_statement_classes(
6.     "performance_schema_max_statement_classes",
7.     "Maximum number of statement instruments.",
8.     READ_ONLY GLOBAL_VAR(pfs_param.m_statement_class_sizing),
9.     CMD_LINE(REQUIRED_ARG), VALID_RANGE(0, 256 * 2),
10.     DEFAULT((ulong)SQLCOM_END + (ulong)COM_END + 5 +
11.             SP_PSI_STATEMENT_INFO_COUNT + CLONE_PSI_STATEMENT_COUNT),
12.     BLOCK_SIZE(1), PFS_TRAILING_PROPERTIES);

复制代码

四、问题总结

在GreatSQL的sp添加新的sp_instr需要相应增加对应的参数值以防止内存溢出，如果其他的功能也要做类似的修改，也要先仔细调查一下有没有涉及相关的参数配置或者宏定义，不然就会遇到各种莫名其妙的问题，调查起来也很花时间。
这次发现的问题属于新添加功能带入的bug，在实际开发应用中类似的问题也要注意，一不小心就会踩坑。
上述问题在MySQL/Percona中同样存在。

Enjoy GreatSQL
来源:https://www.cnblogs.com/greatsql/p/18178998
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！