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

一、问题发现

在一次开发中使用 mysql prepare 以后，从 prepare 直接取 name 赋值给 lex->prepared_stmt_name 然后给 execute 用，发现有一定概率找不到 prepare stmt 的 name，于是开始动手调查问题发生的原因。

sql语句示例：

create table t1 (a int, b varchar(10));
prepare dbms_sql_stmt4 from 'insert into t1 values (1,''11'')';
execute dbms_sql_stmt4;

报错：
sql error [1243] [hy000]: unknown prepared statement handler (dbms_sql_stmt4??p??]uu) given to execute

二、问题调查过程

1、根据报错信息找到对应源码，发现在mysql_sql_stmt_execute里面有判断当找不到 stmt name 时候报错信息。

这里的 name 此时已经是乱码了。

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、这个 lex->prepared_stmt_name 是从 prepare name 中赋值的，于是调查 prepare 这个 name 设置的函数。

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 后面出现了乱码，说明 m_nam e最后不是 \0 结束，而是别的字符。

3、接着到 execute 的函数看一下这个 name 值，发现确实后面跟的不是 \0 结束符，而是变为乱码。于是这里当然会报错找不到该 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;
# 结果报错了。

三、问题解决方案

通过以上 gdb 跟踪过程我们可以发现 prepare 存 name 的时候存放方式有问题导致 name 最后没有结束符，于是回头看一下set_name 的代码，于是发现以下代码问题：

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;
}
# 箭头处发现存 name 时候申请的内存长度为 name_arg.length，没有把最后的 \0 一起存放进去，导致最后少了结束符，这就有概率导致查找 name 出错。

于是把 name_arg.length 改为 name_arg.length+1，重新编译代码问题解决。