From 06a1df91813ea2c39f7312bcf8af972c7e8a926f Mon Sep 17 00:00:00 2001 From: Davi Arnaut Date: Thu, 17 Dec 2009 15:58:38 -0200 Subject: Bug#48983: Bad strmake calls (length one too long) The problem is a somewhat common misusage of the strmake function. The strmake(dst, src, len) function writes at most /len/ bytes to the string pointed to by src, not including the trailing null byte. Hence, if /len/ is the exact length of the destination buffer, a one byte buffer overflow can occur if the length of the source string is equal to or greater than /len/. client/mysqldump.c: Make room for the trailing null byte. libmysql/libmysql.c: Add comment, there is enough room in the buffer. Increase buffer length, two strings are concatenated. libmysqld/lib_sql.cc: Make room for the trailing null byte. mysys/default.c: Make room for the trailing null bytes. mysys/mf_pack.c: Make room for the trailing null byte. server-tools/instance-manager/commands.cc: Copy only if overflow isn't possible in both cases. server-tools/instance-manager/listener.cc: Make room for the trailing null byte. sql/log.cc: Make room for the trailing null byte. sql/sp_pcontext.h: Cosmetic fix. sql/sql_acl.cc: MAX_HOSTNAME already specifies space for the trailing null byte. sql/sql_parse.cc: Make room for the trailing null byte. sql/sql_table.cc: Make room for the trailing null byte. --- sql/sql_table.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sql/sql_table.cc') diff --git a/sql/sql_table.cc b/sql/sql_table.cc index e32c17bc678..9432c5c3f89 100644 --- a/sql/sql_table.cc +++ b/sql/sql_table.cc @@ -742,7 +742,7 @@ static int mysql_prepare_table(THD *thd, HA_CREATE_INFO *create_info, !(sql_field->charset= get_charset_by_csname(sql_field->charset->csname, MY_CS_BINSORT,MYF(0)))) { - char tmp[64]; + char tmp[65]; strmake(strmake(tmp, save_cs->csname, sizeof(tmp)-4), STRING_WITH_LEN("_bin")); my_error(ER_UNKNOWN_COLLATION, MYF(0), tmp); -- cgit v1.2.1 From eab2be0aeed0459c505578a716f8b0ae88a8f365 Mon Sep 17 00:00:00 2001 From: Mattias Jonsson Date: Mon, 18 Jan 2010 17:49:18 +0100 Subject: Bug#47343: InnoDB fails to clean-up after lock wait timeout on REORGANIZE PARTITION There were several problems which lead to this this, all related to bad error handling. 1) There was several bugs preventing the ddl-log to be used for cleaning up created files on error. 2) The error handling after the copy partition rows did not close and unlock the tables, resulting in deletion of partitions which were in use, which lead InnoDB to put the partition to drop in a background queue. sql/ha_partition.cc: Bug#47343: InnoDB fails to clean-up after lock wait timeout on REORGANIZE PARTITION Better error handling, if partition has been created/opened/locked then make sure it is unlocked and closed before returning error. The delete of the newly created partition is handled by the ddl-log. sql/sql_parse.cc: Bug#47343: InnoDB fails to clean-up after lock wait timeout on REORGANIZE PARTITION Fix a bug found when experimenting, thd could really be NULL here, as mentioned in the function header. sql/sql_partition.cc: Bug#47343: InnoDB fails to clean-up after lock wait timeout on REORGANIZE PARTITION Used the correct .frm shadow name to put into the ddl-log. Really use the ddl-log to handle errors. sql/sql_table.cc: Bug#47343: InnoDB fails to clean-up after lock wait timeout on REORGANIZE PARTITION Fixes of the ddl-log when used as error recovery (no crash). When executing an entry from memory (not read from disk) the name_len was not set correctly. --- sql/sql_table.cc | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) (limited to 'sql/sql_table.cc') diff --git a/sql/sql_table.cc b/sql/sql_table.cc index 3b7354111ba..0e36ecfcb46 100644 --- a/sql/sql_table.cc +++ b/sql/sql_table.cc @@ -647,7 +647,7 @@ static bool read_ddl_log_file_entry(uint entry_no) Write one entry from ddl log file SYNOPSIS write_ddl_log_file_entry() - entry_no Entry number to read + entry_no Entry number to write RETURN VALUES TRUE Error FALSE Success @@ -748,10 +748,10 @@ static uint read_ddl_log_header() else successful_open= TRUE; } - entry_no= uint4korr(&file_entry_buf[DDL_LOG_NUM_ENTRY_POS]); - global_ddl_log.name_len= uint4korr(&file_entry_buf[DDL_LOG_NAME_LEN_POS]); if (successful_open) { + entry_no= uint4korr(&file_entry_buf[DDL_LOG_NUM_ENTRY_POS]); + global_ddl_log.name_len= uint4korr(&file_entry_buf[DDL_LOG_NAME_LEN_POS]); global_ddl_log.io_size= uint4korr(&file_entry_buf[DDL_LOG_IO_SIZE_POS]); DBUG_ASSERT(global_ddl_log.io_size <= sizeof(global_ddl_log.file_entry_buf)); @@ -832,6 +832,7 @@ static bool init_ddl_log() goto end; global_ddl_log.io_size= IO_SIZE; + global_ddl_log.name_len= FN_LEN; create_ddl_log_file_name(file_name); if ((global_ddl_log.file_id= my_create(file_name, CREATE_MODE, @@ -884,6 +885,13 @@ static int execute_ddl_log_action(THD *thd, DDL_LOG_ENTRY *ddl_log_entry) { DBUG_RETURN(FALSE); } + DBUG_PRINT("ddl_log", + ("execute type %c next %u name '%s' from_name '%s' handler '%s'", + ddl_log_entry->action_type, + ddl_log_entry->next_entry, + ddl_log_entry->name, + ddl_log_entry->from_name, + ddl_log_entry->handler_name)); handler_name.str= (char*)ddl_log_entry->handler_name; handler_name.length= strlen(ddl_log_entry->handler_name); init_sql_alloc(&mem_root, TABLE_ALLOC_BLOCK_SIZE, 0); @@ -1091,6 +1099,15 @@ bool write_ddl_log_entry(DDL_LOG_ENTRY *ddl_log_entry, DBUG_RETURN(TRUE); } error= FALSE; + DBUG_PRINT("ddl_log", + ("write type %c next %u name '%s' from_name '%s' handler '%s'", + (char) global_ddl_log.file_entry_buf[DDL_LOG_ACTION_TYPE_POS], + ddl_log_entry->next_entry, + (char*) &global_ddl_log.file_entry_buf[DDL_LOG_NAME_POS], + (char*) &global_ddl_log.file_entry_buf[DDL_LOG_NAME_POS + + FN_LEN], + (char*) &global_ddl_log.file_entry_buf[DDL_LOG_NAME_POS + + (2*FN_LEN)])); if (write_ddl_log_file_entry((*active_entry)->entry_pos)) { error= TRUE; -- cgit v1.2.1