GreatSQL的sp中添加新的sp_instr引入的bug解析
一、問題發(fā)現(xiàn)
在一次開發(fā)中用到的sp需要添加新的sp_instr以滿足需求，但是添加了數(shù)個(gè)sp_instr以后發(fā)現(xiàn)執(zhí)行新的sp會(huì)發(fā)生core。
注：本次使用的GreatSQL 8.0.32-25
1、sp_head.cc的init_sp_psi_keys()代碼里面添加10個(gè)新的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相關(guān)實(shí)現(xiàn)代碼，其中sql_yacc.yy和sql_lex.cc需要相應(yīng)添加新的語法。
3、sp_rcontext.h處在·class sp_rcontext里面添加幾個(gè)新的成員變量。下面代碼只是示例，不具有實(shí)際使用價(jià)值。
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、創(chuàng)建新的sp，里面包含新的sp_instr_stmt的內(nèi)容，然后call該sp，結(jié)果發(fā)現(xiàn)代碼邏輯處因?yàn)橐粋€(gè)list里面member的值被清空了，然后導(dǎo)致crash。下面是相關(guān)的堆棧。因?yàn)樯婕按a機(jī)密，只截圖開源部分相關(guān)堆棧。
#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處的信息，發(fā)現(xiàn)list里面的值被清空了。
(gdb) p tmp
$1 = (list_node *) 0x0二、問題調(diào)查過程
1、仔細(xì)檢查代碼發(fā)現(xiàn)代碼邏輯沒有問題，list的值確實(shí)都有成功賦值，但是運(yùn)行時(shí)候卻發(fā)現(xiàn)list被清空，顯然這是別的地方內(nèi)存泄漏或者內(nèi)存溢出導(dǎo)致list的元素空間被占用了或者被清空了。把sp的代碼換成別的，有時(shí)候會(huì)crash有時(shí)候不會(huì)crash，觸發(fā)機(jī)制也不明朗，不知道具體哪句代碼導(dǎo)致的內(nèi)存泄漏。
2、于是回頭繼續(xù)看剛開始添加代碼的地方，猜想是不是跟我添加了10個(gè)sp_instr_stmt有關(guān)，因?yàn)橄嚓P(guān)的數(shù)組或者內(nèi)存沒有添加擴(kuò)容，很有可能因?yàn)檫@個(gè)導(dǎo)致內(nèi)存溢出。
3、定位出疑似問題地方，就可以著手開始調(diào)查相關(guān)代碼了。查看相關(guān)添加sp_instr的代碼。
添加sp_instr實(shí)現(xiàn)代碼如下：
mysql_statement_register(category, &sp_instr_stmt1::psi_info, 1);
于是繼續(xù)往下面調(diào)查mysql_statement_register實(shí)現(xiàn)的代碼，
看到這里果然用到了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相關(guān)的參數(shù)配置的地方，
看到這里有一個(gè)SP_PSI_STATEMENT_INFO_COUNT宏定義，這個(gè)值跟sp_instr的數(shù)量有關(guān)。
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);
繼續(xù)全文搜索，發(fā)現(xiàn)在sp_head.h定義了，這里的值為16，
數(shù)了一下現(xiàn)存的sp_instr個(gè)數(shù)剛好為16個(gè)，至此問題原因發(fā)現(xiàn)，
因?yàn)槲壹恿?0個(gè)sp_instr，而這個(gè)宏定義的值沒有跟著增加，導(dǎo)致內(nèi)存溢出。
#define SP_PSI_STATEMENT_INFO_COUNT 16三、問題解決方案
通過以上代碼解析后，就可以修改相關(guān)問題代碼，只要作如下修改即可。重新編譯完，問題解決。
sp_head.h修改SP_PSI_STATEMENT_INFO_COUNT宏定義（這里的26=16+10）：
#define SP_PSI_STATEMENT_INFO_COUNT 26
因?yàn)樵黾恿薙ys_pfs_max_statement_classes的default值，
因此相關(guān)配置范圍也要跟著增加，因此把range相應(yīng)加大。
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);四、問題總結(jié)
在GreatSQL的sp添加新的sp_instr需要相應(yīng)增加對(duì)應(yīng)的參數(shù)值以防止內(nèi)存溢出，如果其他的功能也要做類似的修改，也要先仔細(xì)調(diào)查一下有沒有涉及相關(guān)的參數(shù)配置或者宏定義，不然就會(huì)遇到各種莫名其妙的問題，調(diào)查起來也很花時(shí)間。
這次發(fā)現(xiàn)的問題屬于新添加功能帶入的bug，在實(shí)際開發(fā)應(yīng)用中類似的問題也要注意，一不小心就會(huì)踩坑。
上述問題在MySQL/Percona中同樣存在。
