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

Bug #1628964 reported by Tomislav Plavcic
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.5
In Progress
High
Laurynas Biveinis
5.6
Triaged
High
Laurynas Biveinis
5.7
Triaged
High
Laurynas Biveinis

Bug Description

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.

Tags: memory-se
Revision history for this message
Tomislav Plavcic (tplavcic) wrote :
tags: added: memory-se
Revision history for this message
Tomislav Plavcic (tplavcic) wrote :
Download full text (12.1 KiB)

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*...

Revision history for this message
Tomislav Plavcic (tplavcic) wrote :
Download full text (3.9 KiB)

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...

Read more...

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.