Valgrind: Unaddressable bytes found during client check request at dtuple_validate by page_cur_search_with_match

[Tomislav Plavcic]

Here's the part of Valgrind output from error log and the whole error log is attached.

==17453== Thread 29:
==17453== Unaddressable byte(s) found during client check request
==17453== at 0x1B9DDFA: dtuple_validate(dtuple_t const*) (data0data.cc:248)
==17453== by 0x1994836: page_cur_search_with_match(buf_block_t const*, dict_index_t const*, dtuple_t const*, page_cur_mode_t, unsigned long*, unsigned long*, page_cur_t*, rtr_info*) (page0cur.cc:434)
==17453== by 0x1B34F24: btr_cur_search_to_nth_level_with_no_latch(dict_index_t*, unsigned long, dtuple_t const*, page_cur_mode_t, btr_cur_t*, char const*, unsigned long, mtr_t*, bool) (btr0cur.cc:2128)
==17453== by 0x19F9344: row_ins_sorted_clust_index_entry(unsigned long, dict_index_t*, dtuple_t*, unsigned long, que_thr_t*) (row0ins.cc:2707)
==17453== by 0x19FAE75: row_ins_clust_index_entry(dict_index_t*, dtuple_t*, que_thr_t*, unsigned long, bool) (row0ins.cc:3300)
==17453== by 0x1A1C487: row_insert_for_mysql_using_cursor(unsigned char const*, row_prebuilt_t*) (row0mysql.cc:1593)
==17453== by 0x1A1D02F: row_insert_for_mysql(unsigned char const*, row_prebuilt_t*) (row0mysql.cc:1854)
==17453== by 0x18B2C14: ha_innobase::intrinsic_table_write_row(unsigned char*) (ha_innodb.cc:7750)
==17453== by 0x18B2CD9: ha_innobase::write_row(unsigned char*) (ha_innodb.cc:7774)
==17453== by 0xF1CD11: handler::ha_write_row(unsigned char*) (handler.cc:8228)
==17453== by 0x14E0A48: end_write(JOIN*, QEP_TAB*, bool) (sql_executor.cc:3377)
==17453== by 0x14E3F9A: QEP_tmp_table::put_record(bool) (sql_executor.cc:4645)
==17453== by 0x14E4D44: QEP_tmp_table::put_record() (sql_executor.h:248)
==17453== by 0x14DB2F0: sub_select_op(JOIN*, QEP_TAB*, bool) (sql_executor.cc:1077)
==17453== by 0x14DC20C: evaluate_join_record(JOIN*, QEP_TAB*) (sql_executor.cc:1639)
==17453== by 0x14DB64C: sub_select(JOIN*, QEP_TAB*, bool) (sql_executor.cc:1291)
==17453== by 0x14DAECD: do_select(JOIN*) (sql_executor.cc:944)
==17453== by 0x14D8E4E: JOIN::exec() (sql_executor.cc:199)
==17453== by 0x15781D1: handle_query(THD*, LEX*, Query_result*, unsigned long long, unsigned long long) (sql_select.cc:184)
==17453== by 0x152AC65: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5393)
==17453== by 0x1523D58: mysql_execute_command(THD*, bool) (sql_parse.cc:2891)
==17453== by 0x152BC42: mysql_parse(THD*, Parser_state*) (sql_parse.cc:5838)
==17453== by 0x1520892: dispatch_command(THD*, COM_DATA const*, enum_server_command) (sql_parse.cc:1447)
==17453== by 0x151F7AC: do_command(THD*) (sql_parse.cc:1010)
==17453== by 0x1661847: handle_connection (connection_handler_per_thread.cc:312)
==17453== by 0x1D0C13B: pfs_spawn_thread (pfs.cc:2188)
==17453== by 0x5075DC4: start_thread (pthread_create.c:308)
==17453== by 0x6E5CCEC: clone (clone.S:113)

TEST CASE:
==========
DROP DATABASE test;CREATE DATABASE test;USE test;
CREATE TABLE ti(g BLOB,id INT,KEY (id)) ENGINE=MEMORY;
INSERT INTO ti VALUES('test',5);
INSERT INTO ti VALUES(0,4);
SET @@session.sql_buffer_result=1;
select * from ti;

I've tried with InnoDB as well but the issue wasn't visible there.

[Tomislav Plavcic (tplavcic)]

Oracle mysql is blocking creation of the table with text/block column in this case, and I get some different? issue on PS 5.6/5.5.

5.6:
====
==31697== Thread 24:
==31697== Invalid read of size 2
==31697== at 0x4C2E2A0: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31697== by 0xDEE64B: _mi_rec_pack (mi_dynrec.c:997)
==31697== by 0xDEBD0D: _mi_write_blob_record (mi_dynrec.c:289)
==31697== by 0xE12D38: mi_write (mi_write.c:142)
==31697== by 0xDCD1B9: ha_myisam::write_row(unsigned char*) (ha_myisam.cc:826)
==31697== by 0x655284: handler::ha_write_row(unsigned char*) (handler.cc:7736)
==31697== by 0x7C88AC: end_write(JOIN*, st_join_table*, bool) (sql_executor.cc:3012)
==31697== by 0x7CC0B9: QEP_tmp_table::put_record(bool) (sql_executor.cc:4320)
==31697== by 0x7CCC1A: QEP_tmp_table::put_record() (sql_executor.h:242)
==31697== by 0x7C4582: sub_select_op(JOIN*, st_join_table*, bool) (sql_executor.cc:1070)
==31697== by 0x7C5288: evaluate_join_record(JOIN*, st_join_table*) (sql_executor.cc:1604)
==31697== by 0x7C4871: sub_select(JOIN*...

[Tomislav Plavcic (tplavcic)]

Same root cause but different effect (this could possibly be more reduced but didn't bother):
DROP DATABASE test;CREATE DATABASE test;USE test;
CREATE TABLE t1(c1 NUMERIC,c2 CHAR (1),c3 INT(1),c4 VARCHAR(1) KEY,c5 NUMERIC UNIQUE KEY,c6 DECIMAL(0,0) DEFAULT 3.141592);
ALTER TABLE t1 engine=MEMORY;
INSERT INTO t1(c1,c2,c3) VALUES(0,0,0);
ALTER TABLE t1 CHANGE c1 c1 BLOB;
ALTER TABLE t1 MODIFY c1 INT;

Error log:
==13759== Thread 38:
==13759== Invalid read of size 1
==13759== at 0x1DE1EC5: my_strntoull10rnd_8bit (ctype-simple.c:1444)
==13759== by 0xED2D4D: Field_num::get_int(charset_info_st const*, char const*, unsigned long, long long*, unsigned long long, long long, long long) (field.cc:1452)
==13759== by 0xED9C9B: Field_long::store(char const*, unsigned long, charset_info_st const*) (field.cc:4013)
==13759== by 0x16BA83B: do_field_string(Copy_field*) (field_conv.cc:366)
==13759== by 0x16BB33C: Copy_field::invoke_do_copy2(Copy_field*) (field_conv.cc:616)
==13759== by 0x16BA2DD: do_copy_null(Copy_field*) (field_conv.cc:265)
==13759== by 0x16BB30C: Copy_field::invoke_do_copy(Copy_field*) (field_conv.cc:609)
==13759== by 0x15C4D0A: copy_data_between_tables(PSI_stage_progress*, TABLE*, TABLE*, List<Create_field>&, unsigned long long*, unsigned long long*, Alter_info::enum_enable_or_disable, Alter_table_ctx*) (sql_table.cc:10594)
==13759== by 0x15C3698: mysql_alter_table(THD*, char const*, char const*, st_ha_create_information*, TABLE_LIST*, Alter_info*) (sql_table.cc:10107)
==13759== by 0x1738780: Sql_cmd_alter_table::execute(THD*) (sql_alter.cc:320)
==13759== by 0x1529A44: mysql_execute_command(THD*, bool) (sql_parse.cc:5065)
==13759== by 0x152BC42: mysql_parse(THD*, Parser_state*) (sql_parse.cc:5838)
==13759== by 0x1520892: dispatch_command(THD*, COM_DATA const*, enum_server_command) (sql_parse.cc:1447)
==13759== by 0x151F7AC: do_command(THD*) (sql_parse.cc:1010)
==13759== by 0x162FBA9: threadpool_process_request(THD*) (threadpool_common.cc:254)
==13759== by 0x164936C: handle_event(connection_t*) (threadpool_unix.cc:1569)
==13759== by 0x16494EF: worker_main(void*) (threadpool_unix.cc:1621)
==13759== by 0x1D0C13B: pfs_spawn_thread (pfs.cc:2188)
==13759== by 0x4E3CDC4: start_thread (pthread_create.c:308)
==13759== by 0x6C23CEC: clone (clone.S:113)
==13759== Address 0x32cbe5d0 is 0 bytes inside a block of size 16 free'd
==13759== at 0x18670EB: my_free (my_malloc.c:132)
==13759== by 0xE73A7D: String::mem_free() (sql_string.h:337)
==13759== by 0xEF6E5D: Field_blob::mem_free() (field.h:3854)
==13759== by 0xEF68E8: Field_blob::~Field_blob() (in /sda/workdir-tomislav/percona-server-5.7.14-7-linux-x86_64-debug-valgrind-f983b95/bin/mysqld)
==13759== by 0xEF699B: Field_blob::~Field_blob() (field.h:3724)
==13759== by 0x161E5B1: closefrm(TABLE*, bool) (table.cc:3457)
==13759== by 0x149622A: close_temporary(TABLE*, bool, bool) (sql_base.cc:2528)
==13759== by 0x14960F9: close_temporary_table(THD*, TABLE*, bool, bool) (sql_base.cc:2498)
==13759== by 0x15C39E1: mysql_alter_table(THD*, char const*, char const*, st_ha_create_information*, TABLE_LIST*, Alter_info*) (sql_table.c...

[Laurynas Biveinis (laurynas-biveinis)]

The root issue is that such ordering of columns is not supported by MEMORY engine: all the key columns must always come before any BLOB columns, and the CREATE TABLE / ALTER TABLE ADD INDEX / etc statements that violate this must be rejected outright. This is tracked in bug 1731483, and I am going to close this bug as its duplicate.