GreatSQL的sp中添加新的sp_instr引入的bug解析
作者：wuyy
在GreatSQL的sp添加新的sp_instr需要相應增加對應的參數值以防止內存溢出，如果其他的功能也要做類似的修改，也要先仔細調查一下有沒有涉及相關的參數配置或者宏定義，不然就會遇到各種莫名其妙的問題，調查起來也很花時間。
一、問題發現
在一次開發中用到的sp需要添加新的sp_instr以滿足需求，但是添加了數個sp_instr以后發現執行新的sp會發生core。
注：本次使用的GreatSQL 8.0.32-25
1、sp_head.cc的init_sp_psi_keys()代碼里面添加10個新的sp_instr：
void init_sp_psi_keys() {
mysql_statement_register(category, &sp_instr_stmt1::psi_info, 1);
mysql_statement_register(category, &sp_instr_stmt2::psi_info, 1);
mysql_statement_register(category, &sp_instr_stmt3::psi_info, 1);
......
mysql_statement_register(category, &sp_instr_stmt10::psi_info, 1);
}2、sp_instr.cc里面添加新的sp_instr_stmt相關實現代碼，其中sql_yacc.yy和sql_lex.cc需要相應添加新的語法。
3、sp_rcontext.h處在·class sp_rcontext里面添加幾個新的成員變量。下面代碼只是示例，不具有實際使用價值。
Field *m_return_value_fld_tmp{m_return_value_fld};
Field *m_return_value_fld_tmp1{m_return_value_fld};
Field *m_return_value_fld_tmp2{m_return_value_fld};4、創建新的sp，里面包含新的sp_instr_stmt的內容，然后call該sp，結果發現代碼邏輯處因為一個list里面member的值被清空了，然后導致crash。下面是相關的堆棧。因為涉及代碼機密，只截圖開源部分相關堆棧。
#0 0x0000555558f3f3d9 in base_list_iterator::next_fast (this=0x7fffe01e9de0)
at /sql/sql_list.h:371
#1 0x0000555558fc59b7 in List_iterator_fast<Create_field>::operator++ (this=0x7fffe01e9de0)
at /sql/sql_list.h:605
#2 0x0000555559753ea2 in create_tmp_table_from_fields (thd=0x7fff20001050, field_list=...,
is_virtual=false, select_options=0, alias=0x0)
at /sql/sql_tmp_table.cc:2131
#3 0x0000555559084a09 in Item_xx::val_str (this=0x7fff20b673c8)
at /sql/item_func.cc:10796
#4 0x0000555558fa408b in Item::save_in_field_inner (this=0x7fff20b673c8, field=0x7fff20b9b1a8,
no_conversions=false) at /sql/item.cc:8202
#5 0x0000555558fa3c43 in Item::save_in_field (this=0x7fff20b673c8, field=0x7fff20b9b1a8,
no_conversions=false) at /sql/item.cc:8144
#6 0x0000555559400322 in sp_eval_expr (thd=0x7fff20001050, result_field=0x7fff20b9b1a8,
expr_item_ptr=0x7fff20b67620) at /sql/sp.cc:3613
#7 0x000055555943b1d1 in sp_rcontext::set_variable (this=0x7fff20b85d80, thd=0x7fff20001050,
field=0x7fff20b9b1a8, value=0x7fff20b67620)
at /sql/sp_rcontext.cc:1023
#8 0x0000555558fc3a8e in sp_rcontext::set_variable (this=0x7fff20b85d80, thd=0x7fff20001050,
var_idx=1, value=0x7fff20b67620)
at /sql/sp_rcontext.h:176
打印crash處的信息，發現list里面的值被清空了。
(gdb) p tmp
$1 = (list_node *) 0x0二、問題調查過程
1、仔細檢查代碼發現代碼邏輯沒有問題，list的值確實都有成功賦值，但是運行時候卻發現list被清空，顯然這是別的地方內存泄漏或者內存溢出導致list的元素空間被占用了或者被清空了。把sp的代碼換成別的，有時候會crash有時候不會crash，觸發機制也不明朗，不知道具體哪句代碼導致的內存泄漏。
2、于是回頭繼續看剛開始添加代碼的地方，猜想是不是跟我添加了10個sp_instr_stmt有關，因為相關的數組或者內存沒有添加擴容，很有可能因為這個導致內存溢出。
3、定位出疑似問題地方，就可以著手開始調查相關代碼了。查看相關添加sp_instr的代碼。
添加sp_instr實現代碼如下：
mysql_statement_register(category, &sp_instr_stmt1::psi_info, 1);
于是繼續往下面調查mysql_statement_register實現的代碼，
看到這里果然用到了statement_class_max：
PFS_statement_key register_statement_class(const char *name, uint name_length,
PSI_statement_info *info) {
/* See comments in register_mutex_class */
uint32 index;
PFS_statement_class *entry;
REGISTER_CLASS_BODY_PART(index, statement_class_array, statement_class_max,
name, name_length)
接著查看statement_class_max的賦值的地方：
int init_statement_class(uint statement_class_sizing) {
int result = 0;
statement_class_dirty_count = statement_class_allocated_count = 0;
statement_class_max = statement_class_sizing;
通過搜索代碼查到statement_class_sizing相關的參數配置的地方，
看到這里有一個SP_PSI_STATEMENT_INFO_COUNT宏定義，這個值跟sp_instr的數量有關。
static Sys_var_ulong Sys_pfs_max_statement_classes(
"performance_schema_max_statement_classes",
"Maximum number of statement instruments.",
READ_ONLY GLOBAL_VAR(pfs_param.m_statement_class_sizing),
CMD_LINE(REQUIRED_ARG), VALID_RANGE(0, 256),
DEFAULT((ulong)SQLCOM_END + (ulong)COM_END + 5 +
SP_PSI_STATEMENT_INFO_COUNT + CLONE_PSI_STATEMENT_COUNT),
BLOCK_SIZE(1), PFS_TRAILING_PROPERTIES);
繼續全文搜索，發現在sp_head.h定義了，這里的值為16，
數了一下現存的sp_instr個數剛好為16個，至此問題原因發現，
因為我加了10個sp_instr，而這個宏定義的值沒有跟著增加，導致內存溢出。
#define SP_PSI_STATEMENT_INFO_COUNT 16三、問題解決方案
通過以上代碼解析后，就可以修改相關問題代碼，只要作如下修改即可。重新編譯完，問題解決。
sp_head.h修改SP_PSI_STATEMENT_INFO_COUNT宏定義（這里的26=16+10）：
#define SP_PSI_STATEMENT_INFO_COUNT 26
因為增加了Sys_pfs_max_statement_classes的default值，
因此相關配置范圍也要跟著增加，因此把range相應加大。
static Sys_var_ulong Sys_pfs_max_statement_classes(
"performance_schema_max_statement_classes",
"Maximum number of statement instruments.",
READ_ONLY GLOBAL_VAR(pfs_param.m_statement_class_sizing),
CMD_LINE(REQUIRED_ARG), VALID_RANGE(0, 256 * 2),
DEFAULT((ulong)SQLCOM_END + (ulong)COM_END + 5 +
SP_PSI_STATEMENT_INFO_COUNT + CLONE_PSI_STATEMENT_COUNT),
BLOCK_SIZE(1), PFS_TRAILING_PROPERTIES);四、問題總結
在GreatSQL的sp添加新的sp_instr需要相應增加對應的參數值以防止內存溢出，如果其他的功能也要做類似的修改，也要先仔細調查一下有沒有涉及相關的參數配置或者宏定義，不然就會遇到各種莫名其妙的問題，調查起來也很花時間。
這次發現的問題屬于新添加功能帶入的bug，在實際開發應用中類似的問題也要注意，一不小心就會踩坑。
上述問題在MySQL/Percona中同樣存在。
責任編輯：武曉燕
來源：
GreatSQL社區
