MySQL的prepare使用及遇到bug解析過程

更新時(shí)間：2022年05月07日 15:36:29 作者：GreatSQL

在一次開發(fā)中使用 MySQL PREPARE 以后，從 prepare 直接取 name 賦值給 lex->prepared_stmt_name 然后給 EXECUTE 用，發(fā)現(xiàn)有一定概率找不到 prepare stmt 的 name，于是開始動(dòng)手調(diào)查問題發(fā)生的原因，本文給大家分享mysql prepare使用及問題解決，感興趣的朋友一起看看吧

一、問題發(fā)現(xiàn)

在一次開發(fā)中使用 MySQL PREPARE 以后，從 prepare 直接取 name 賦值給 lex->prepared_stmt_name 然后給 EXECUTE 用，發(fā)現(xiàn)有一定概率找不到 prepare stmt 的 name，于是開始動(dòng)手調(diào)查問題發(fā)生的原因。

SQL語(yǔ)句示例：

CREATE TABLE t1 (a INT, b VARCHAR(10));
PREPARE dbms_sql_stmt4 FROM 'INSERT INTO t1 VALUES (1,''11'')';
EXECUTE dbms_sql_stmt4;

報(bào)錯(cuò)：
SQL Error [1243] [HY000]: Unknown prepared statement handler (dbms_sql_stmt4??p??]UU) given to EXECUTE

二、問題調(diào)查過程

1、根據(jù)報(bào)錯(cuò)信息找到對(duì)應(yīng)源碼，發(fā)現(xiàn)在MySQL_sql_stmt_execute里面有判斷當(dāng)找不到 stmt name 時(shí)候報(bào)錯(cuò)信息。

這里的 name 此時(shí)已經(jīng)是亂碼了。

void MySQL_sql_stmt_execute(THD *thd) {
  LEX *lex = thd->lex;
  const LEX_CSTRING &name = lex->prepared_stmt_name;
  DBUG_TRACE;
  DBUG_PRINT("info", ("EXECUTE: %.*s\n", (int)name.length, name.str));
  Prepared_statement *stmt;
  if (!(stmt = thd->stmt_map.find_by_name(name))) {
    my_error(ER_UNKNOWN_STMT_HANDLER, MYF(0), static_cast<int>(name.length),
             name.str, "EXECUTE");
    return;
  }

2、這個(gè) lex->prepared_stmt_name 是從 prepare name 中賦值的，于是調(diào)查 prepare 這個(gè) name 設(shè)置的函數(shù)。

bool Prepared_statement::set_name(const LEX_CSTRING &name_arg) {
  m_name.length = name_arg.length;
  m_name.str = static_cast<char *>(
      memdup_root(m_arena.mem_root, name_arg.str, name_arg.length));
  return m_name.str == nullptr;
}

gdb 跟蹤代碼：

Thread 46 "MySQLd" hit Breakpoint 1, Prepared_statement::set_name (this=0x7fff2cbf3250, name_arg=...)
    at /home/wuyy/greatdb/gitmerge/percona-server/sql/sql_prepare.cc:2447
2447	bool Prepared_statement::set_name(const LEX_CSTRING &name_arg) {
(gdb) n
2448	  m_name.length = name_arg.length;
(gdb) 
2450	      memdup_root(m_arena.mem_root, name_arg.str, name_arg.length));
(gdb) 
2449	  m_name.str = static_cast<char *>(
(gdb) 
2451	  return m_name.str == nullptr;
(gdb) p m_name
$9 = {
  str = 0x7fff2cd09a68 "dbms_sql_stmt4", '\217' <repeats 98 times>, "FLOAT",
  length = 14
# 可以看到 m_name 后面出現(xiàn)了亂碼，說(shuō)明 m_nam e最后不是 \0 結(jié)束，而是別的字符。

3、接著到 execute 的函數(shù)看一下這個(gè) name 值，發(fā)現(xiàn)確實(shí)后面跟的不是 \0 結(jié)束符，而是變?yōu)閬y碼。于是這里當(dāng)然會(huì)報(bào)錯(cuò)找不到該 stmt name 了。

Thread 46 "MySQLd" hit Breakpoint 2, MySQL_sql_stmt_execute (thd=0x7fff2c002688)
    at /home/wuyy/greatdb/gitmerge/percona-server/sql/sql_prepare.cc:1944
1944	void MySQL_sql_stmt_execute(THD *thd) {
(gdb) n
1945	  LEX *lex = thd->lex;
(gdb) 
1946	  const LEX_CSTRING &name = lex->prepared_stmt_name;
(gdb) 
1947	  DBUG_TRACE;
(gdb) p name
$10 = (const LEX_CSTRING &) @0x7fff2cd501e0: {
  str = 0x7fff2cd09a68 "dbms_sql_stmt4\217\217p\271\221]UU",
  length = 22
}
(gdb) n
1948	  DBUG_PRINT("info", ("EXECUTE: %.*s\n", (int)name.length, name.str));
(gdb) 
1951	  if (!(stmt = thd->stmt_map.find_by_name(name))) {
(gdb) 
1953	             name.str, "EXECUTE");
(gdb) 
1952	    my_error(ER_UNKNOWN_STMT_HANDLER, MYF(0), static_cast<int>(name.length),
(gdb) 
1954	    return;
# 結(jié)果報(bào)錯(cuò)了。

三、問題解決方案

通過以上 gdb 跟蹤過程我們可以發(fā)現(xiàn) prepare 存 name 的時(shí)候存放方式有問題導(dǎo)致 name 最后沒有結(jié)束符，于是回頭看一下set_name 的代碼，于是發(fā)現(xiàn)以下代碼問題：

bool Prepared_statement::set_name(const LEX_CSTRING &name_arg) {
  m_name.length = name_arg.length;
  m_name.str = static_cast<char *>(
      memdup_root(m_arena.mem_root, name_arg.str, name_arg.length));←這里問題
  return m_name.str == nullptr;
}
# 箭頭處發(fā)現(xiàn)存 name 時(shí)候申請(qǐng)的內(nèi)存長(zhǎng)度為 name_arg.length，沒有把最后的 \0 一起存放進(jìn)去，導(dǎo)致最后少了結(jié)束符，這就有概率導(dǎo)致查找 name 出錯(cuò)。

于是把 name_arg.length 改為 name_arg.length+1，重新編譯代碼問題解決。