Server segfaults when running prepared statement for versioned tables #1

avodaniel · 2016-09-06T07:25:48Z

It seems that prepared statements are necessary for test of select statements with 'FOR SYSTEM_TIME', since mysql-test doesn't allow statements that change for every test.

Sequence of commands that cause segfault of MariaDB server:

drop table t1;drop table T1;CREATE TABLE t1 (x INT UNSIGNED, y INT UNSIGNED, Sys_start TIMESTAMP(6) GENERATED ALWAYS AS ROW START, Sys_end TIMESTAMP(6) GENERATED ALWAYS AS ROW END, PERIOD FOR SYSTEM_TIME (Sys_start, Sys_end)) WITH SYSTEM VERSIONING;CREATE TABLE T1 (x INT UNSIGNED, y INT UNSIGNED);insert into t1(x, y) values(1, 11),(2,12),(3,13),(4,14),(5,15);insert into T1(x, y) values(1, 11),(2,12),(3,13),(4,14),(5,15);SELECT * FROM t1;SELECT * FROM T1;prepare stmtT1 from 'select x, y from T1';execute stmtT1;prepare stmtt1 from 'select x, y from t1';execute stmtt1;

> CREATE TABLE t1 (x INT UNSIGNED, y INT UNSIGNED, Sys_start TIMESTAMP(6) GENERATED ALWAYS AS ROW START, Sys_end TIMESTAMP(6) GENERATED ALWAYS AS ROW END, PERIOD FOR SYSTEM_TIME (Sys_start, Sys_end)) WITH SYSTEM VERSIONING;
Query OK, 0 rows affected (0.02 sec)

> CREATE TABLE T1 (x INT UNSIGNED, y INT UNSIGNED)
Query OK, 0 rows affected (0.01 sec)

> insert into t1(x, y) values(1, 11),(2,12),(3,13),(4,14),(5,15);
Query OK, 5 rows affected (0.01 sec)
Records: 5  Duplicates: 0  Warnings: 0

> insert into T1(x, y) values(1, 11),(2,12),(3,13),(4,14),(5,15);
Query OK, 5 rows affected (0.01 sec)
Records: 5  Duplicates: 0  Warnings: 0

> SELECT * FROM t1;
+------+------+----------------------------+----------------------------+
| x    | y    | Sys_start                  | Sys_end                    |
+------+------+----------------------------+----------------------------+
|    1 |   11 | 2016-09-06 09:14:35.992804 | 2038-01-19 04:14:07.000000 |
|    2 |   12 | 2016-09-06 09:14:35.992804 | 2038-01-19 04:14:07.000000 |
|    3 |   13 | 2016-09-06 09:14:35.992804 | 2038-01-19 04:14:07.000000 |
|    4 |   14 | 2016-09-06 09:14:35.992804 | 2038-01-19 04:14:07.000000 |
|    5 |   15 | 2016-09-06 09:14:35.992804 | 2038-01-19 04:14:07.000000 |
+------+------+----------------------------+----------------------------+
5 rows in set (0.00 sec)

> SELECT * FROM T1;
+------+------+
| x    | y    |
+------+------+
|    1 |   11 |
|    2 |   12 |
|    3 |   13 |
|    4 |   14 |
|    5 |   15 |
+------+------+
5 rows in set (0.00 sec)

> prepare stmtT1 from 'select x, y from T1';
Query OK, 0 rows affected (0.00 sec)
Statement prepared

> execute stmtT1;
+------+------+
| x    | y    |
+------+------+
|    1 |   11 |
|    2 |   12 |
|    3 |   13 |
|    4 |   14 |
|    5 |   15 |
+------+------+
5 rows in set (0.00 sec)

> prepare stmtt1 from 'select x, y from t1';
Query OK, 0 rows affected (0.00 sec)
Statement prepared

> execute stmtt1;
ERROR 2013 (HY000): Lost connection to MySQL server during query

The text was updated successfully, but these errors were encountered:

midenok · 2016-09-06T11:30:38Z

I confirm reproducibility.

midenok · 2016-09-06T11:51:19Z

(gdb) p $rip
$5 = (void (*)(void)) 0x6b7531 <reinit_stmt_before_use(THD*, LEX*)+317>
(gdb) p/x $rax
$7 = 0x8f8f8f8f8f8f9207

2808          {
2809            /*
2810              We need this rollback because memory allocated in
2811              copy_andor_structure() will be freed
2812            */
2813            thd->change_item_tree((Item**)&sl->where,
   0x00000000006b753f <+331>:   mov    rcx,QWORD PTR [rbp-0x88]
   0x00000000006b7546 <+338>:   mov    rsi,rcx
   0x00000000006b7549 <+341>:   mov    rdi,rdx
   0x00000000006b754c <+344>:   call   rax
   0x00000000006b754e <+346>:   mov    rdx,rax
   0x00000000006b7551 <+349>:   mov    rax,QWORD PTR [rbp-0x70]
   0x00000000006b7555 <+353>:   lea    rcx,[rax+0xa8]

2814                                  sl->prep_where->copy_andor_structure(thd));
   0x00000000006b751d <+297>:   mov    rax,QWORD PTR [rbp-0x70]
   0x00000000006b7521 <+301>:   mov    rax,QWORD PTR [rax+0xb8]
   0x00000000006b7528 <+308>:   mov    rax,QWORD PTR [rax]
   0x00000000006b752b <+311>:   add    rax,0x278
=> 0x00000000006b7531 <+317>:   mov    rax,QWORD PTR [rax]
   0x00000000006b7534 <+320>:   mov    rdx,QWORD PTR [rbp-0x70]
   0x00000000006b7538 <+324>:   mov    rdx,QWORD PTR [rdx+0xb8]
   0x00000000006b755c <+360>:   mov    rax,QWORD PTR [rbp-0x88]
   0x00000000006b7563 <+367>:   mov    rsi,rcx
   0x00000000006b7566 <+370>:   mov    rdi,rax
   0x00000000006b7569 <+373>:   call   0x636f8c <THD::change_item_tree(Item**, Item*)>

midenok · 2016-09-06T12:22:17Z

sl->prep_where is deleted.

(gdb) p *sl->prep_where
Reading in symbols for /home/midenok/src/mariadb/hagrid/src/sql/sql_type.cc...done.
$9 = {
  <Value_source> = {<No data fields>},
  <Type_std_attributes> = {
    collation = {
      collation = 0x8f8f8f8f8f8f8f8f,
      derivation = 2408550287,
      repertoire = 2408550287
    },
    decimals = 2408550287,
    max_length = 2408550287,
    unsigned_flag = 143
  },
  <Type_handler> = {
    _vptr.Type_handler = 0x8f8f8f8f8f8f8f8f
  },
  members of Item:
  join_tab_idx = 2408550287,
  is_expensive_cache = -113 '\217',
  rsize = 2408550287,
  str_value = {
    Ptr = 0x8f8f8f8f8f8f8f8f <error: Cannot access memory at address 0x8f8f8f8f8f8f8f8f>,
    str_length = 2408550287,
    Alloced_length = 2408550287,
    extra_alloc = 2408550287,
    alloced = 143,
    thread_specific = 143,
    str_charset = 0x8f8f8f8f8f8f8f8f
  },
  name = 0x8f8f8f8f8f8f8f8f <error: Cannot access memory at address 0x8f8f8f8f8f8f8f8f>,
  orig_name = 0x8f8f8f8f8f8f8f8f <error: Cannot access memory at address 0x8f8f8f8f8f8f8f8f>,
  next = 0x8f8f8f8f8f8f8f8f,
  name_length = 2408550287,
  marker = -1886417009,
  maybe_null = 143,
  in_rollup = 143,
  null_value = 143,
  with_sum_func = 143,
  with_window_func = 143,
  with_field = 143,
  fixed = 143,
  is_autogenerated_name = 143,
  with_subselect = 143
}

#0  0x00000000006b7528 in reinit_stmt_before_use (thd=0x7f9e61c16070, lex=0x7f9e61d35090) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:2814
#1  0x00000000006bafa8 in Prepared_statement::execute (this=0x7f9e61c6c870, expanded_query=0x7f9e8c3daf00, open_cursor=false) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:4252
#2  0x00000000006b9ec9 in Prepared_statement::execute_loop (this=0x7f9e61c6c870, expanded_query=0x7f9e8c3daf00, open_cursor=false, packet=0x0, packet_end=0x0) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:3908
#3  0x00000000006b7e95 in mysql_sql_stmt_execute (thd=0x7f9e61c16070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:3036
#4  0x000000000069128d in mysql_execute_command (thd=0x7f9e61c16070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:3363
#5  0x000000000069f275 in mysql_parse (thd=0x7f9e61c16070, rawbuf=0x7f9e61c61088 "execute stmtt1", length=14, parser_state=0x7f9e8c3dbf70, is_com_multi=false, is_next_command=false) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:7789

midenok · 2016-09-06T12:44:07Z

(gdb) bbt sql_select.cc:1331
(gdb) ign 4

Initialized:

#0  JOIN::optimize_inner (this=0x7f8e78c61258) at /home/midenok/src/mariadb/hagrid/src/sql/sql_select.cc:1331
#1  0x00000000006d09e0 in JOIN::optimize (this=0x7f8e78c61258) at /home/midenok/src/mariadb/hagrid/src/sql/sql_select.cc:1145
#2  0x00000000006d9095 in mysql_select (thd=Reading in symbols for /home/midenok/src/mariadb/hagrid/src/sql/sql_class.cc...done.
0x7f8e78c16070, tables=0x7f8e78d368f0, wild_num=0, fields=..., conds=Reading in symbols for /home/midenok/src/mariadb/hagrid/src/sql/item.cc...done.
0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2416184064, result=0x7f8e78d36f20, unit=Reading in symbols for /home/midenok/src/mariadb/hagrid/src/sql/sql_lex.cc...done.
0x7f8e78d35158, select_lex=0x7f8e78d358a0) at /home/midenok/src/mariadb/hagrid/src/sql/sql_select.cc:3599
#3  0x00000000006cdd52 in handle_select (thd=0x7f8e78c16070, lex=0x7f8e78d35090, result=0x7f8e78d36f20, setup_tables_done_option=0) at /home/midenok/src/mariadb/hagrid/src/sql/sql_select.cc:377
#4  0x000000000069b81a in execute_sqlcom_select (thd=0x7f8e78c16070, all_tables=0x7f8e78d368f0) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:6317
#5  0x000000000069125c in mysql_execute_command (thd=0x7f8e78c16070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:3352
#6  0x00000000006bb09d in Prepared_statement::execute (this=0x7f8e78c6c870, expanded_query=0x7f8ea325df00, open_cursor=false) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:4277
#7  0x00000000006b9ec9 in Prepared_statement::execute_loop (this=0x7f8e78c6c870, expanded_query=0x7f8ea325df00, open_cursor=false, packet=0x0, packet_end=0x0) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:3908
#8  0x00000000006b7e95 in mysql_sql_stmt_execute (thd=0x7f8e78c16070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:3036
#9  0x000000000069128d in mysql_execute_command (thd=0x7f8e78c16070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:3363
#10 0x000000000069f275 in mysql_parse (thd=0x7f8e78c16070, rawbuf=0x7f8e78c61088 "execute stmtT1", length=14, parser_state=0x7f8ea325ef70, is_com_multi=false, is_next_command=false) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:7789

(gdb) p sel->prep_where
$1 = (Item *) 0x0
(gdb) p &sel->prep_where
$2 = (Item **) 0x7f8e78d35958
(gdb) watch *0x7f8e78d35958
Hardware watchpoint 2: *0x7f8e78d35958

1. Item copied:

#0  THD::check_and_register_item_tree (this=0x7f9d3a016070, place=0x7f9d3a135958, new_value=0x7f9d3a061568) at /home/midenok/src/mariadb/hagrid/src/sql/sql_class.h:3398
#1  0x0000000000682794 in st_select_lex::fix_prepare_information (this=0x7f9d3a1358a0, thd=0x7f9d3a016070, conds=0x7f9d3a061568, having_conds=0x7f9d3a061310) at /home/midenok/src/mariadb/hagrid/src/sql/sql_lex.cc:3664
#2  0x00000000006cfe3c in JOIN::prepare (this=0x7f9d3a061170, tables_init=0x7f9d3a1368f0, wild_num=0x0, conds_init=0x0, og_num=0x0, order_init=0x0, skip_order_by=0x0, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7f9d3a1358a0, unit_arg=0x7f9d3a135158) at /home/midenok/src/mariadb/hagrid/src/sql/sql_select.cc:940
#3  0x000000000076f632 in st_select_lex_unit::prepare (this=0x7f9d3a135158, thd_arg=0x7f9d3a016070, sel_result=0x0, additional_options=0x0) at /home/midenok/src/mariadb/hagrid/src/sql/sql_union.cc:439
#4  0x00000000006b4ebf in mysql_test_select (stmt=0x7f9d3a06c870, tables=0x7f9d3a1368f0) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:1540
#5  0x00000000006b6875 in check_prepared_statement (stmt=0x7f9d3a06c870) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:2325
#6  0x00000000006b99c8 in Prepared_statement::prepare (this=0x7f9d3a06c870, packet=0x7f9d3a061158 "select x, y from t1", packet_len=0x13) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:3700
#7  0x00000000006b7486 in mysql_sql_stmt_prepare (thd=0x7f9d3a016070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:2755
#8  0x0000000000691377 in mysql_execute_command (thd=0x7f9d3a016070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:3358
#9  0x000000000069f373 in mysql_parse (thd=0x7f9d3a016070, rawbuf=0x7f9d3a061088 "prepare stmtt1 from 'select x, y from t1'", length=0x29, parser_state=0x7f9d64fc2f70, is_com_multi=0x0, is_next_command=0x0) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:7789

2. Item deleted:

#0  0x0000000000931a1e in Item_cond::~Item_cond (this=0x7f80b3461c70, __in_chrg=<optimized out>) at /home/midenok/src/mariadb/hagrid/src/sql/item_cmpfunc.h:2002
#1  0x0000000000932758 in Item_cond_and::~Item_cond_and (this=0x7f80b3461c70, __in_chrg=<optimized out>) at /home/midenok/src/mariadb/hagrid/src/sql/item_cmpfunc.h:2365
#2  0x000000000093278c in Item_cond_and::~Item_cond_and (this=0x7f80b3461c70, __in_chrg=<optimized out>) at /home/midenok/src/mariadb/hagrid/src/sql/item_cmpfunc.h:2365
#3  0x000000000065a1ab in Item::delete_self (this=0x7f80b3461c70) at /home/midenok/src/mariadb/hagrid/src/sql/item.h:1729
#4  0x0000000000651af7 in Query_arena::free_items (this=0x7f80b3416088) at /home/midenok/src/mariadb/hagrid/src/sql/sql_class.cc:3637
#5  0x000000000064d2b7 in THD::cleanup_after_query (this=0x7f80b3416070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_class.cc:2262
#6  0x00000000006b9409 in Prepared_statement::cleanup_stmt (this=0x7f80b346c870) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:3544
#7  0x00000000006b9bb9 in Prepared_statement::prepare (this=0x7f80b346c870, packet=0x7f80b3461158 "select x, y from t1", packet_len=19) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:3739
#8  0x00000000006b74da in mysql_sql_stmt_prepare (thd=0x7f80b3416070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:2755
#9  0x00000000006913cb in mysql_execute_command (thd=0x7f80b3416070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:3358
#10 0x000000000069f3c7 in mysql_parse (thd=0x7f80b3416070, rawbuf=0x7f80b3461088 "prepare stmtt1 from 'select x, y from t1'", length=41, parser_state=0x7f80de161f70, is_com_multi=false, is_next_command=false) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:7789

3. Item accessed:

#0  0x00000000006b7528 in reinit_stmt_before_use (thd=0x7f9e61c16070, lex=0x7f9e61d35090) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:2814
#1  0x00000000006bafa8 in Prepared_statement::execute (this=0x7f9e61c6c870, expanded_query=0x7f9e8c3daf00, open_cursor=false) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:4252
#2  0x00000000006b9ec9 in Prepared_statement::execute_loop (this=0x7f9e61c6c870, expanded_query=0x7f9e8c3daf00, open_cursor=false, packet=0x0, packet_end=0x0) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:3908
#3  0x00000000006b7e95 in mysql_sql_stmt_execute (thd=0x7f9e61c16070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_prepare.cc:3036
#4  0x000000000069128d in mysql_execute_command (thd=0x7f9e61c16070) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:3363
#5  0x000000000069f275 in mysql_parse (thd=0x7f9e61c16070, rawbuf=0x7f9e61c61088 "execute stmtt1", length=14, parser_state=0x7f9e8c3dbf70, is_com_multi=false, is_next_command=false) at /home/midenok/src/mariadb/hagrid/src/sql/sql_parse.cc:7789

midenok · 2016-09-06T16:13:24Z

Daniel, please test.

avodaniel · 2016-09-07T09:29:18Z

I tried commands from first comment and they work. I also added prepared statements for versioned tables to test for SELECT statement and it also work.

midenok · 2016-09-07T16:26:24Z

Thanks!

Fixing the asymmetry in the array field_types_merge_rules[][] which caused data loss when mixing FLOAT + BIGINT in UNIONs or hybrid functions: 1. FLOAT + INT = DOUBLE 2. FLOAT + BIGINT = FLOAT 3. INT + FLOAT = DOUBLE 4. BIGINT + FLOAT = DOUBLE Now FLOAT + BIGINT (as in #2) also produces DOUBLE, like the cases #1,#3,#4 do.

…LUE_ON_ZERO mode The fixes for these bugs: Bug#27586 Wrong autoinc value assigned by LOAD DATA in the NO_AUTO_VALUE_ON_ZERO mode Bug#22372 Disable spatial key, load data, enable spatial key, crashes table fixed only LOAD DATA INFILE, but did not fix LOAD XML INFILE. This patch does for LOAD XML FILE what patches for Bug#27586 and Bug#22372 earlier did for LOAD DATA INFILE. 1. Fixing the auto_increment problem: a. table->auto_increment_field_not_null is not set to TRUE anymore when a column does not have a corresponding XML tag. b. Adding "table->auto_increment_field_not_null= false" in the end of read_xml_field(). These two changes resemble the patch for Bug#27586. 2. Fixing the GEOMETRY problem: The result for "reset()" was not tested for errors in read_xml_field(), which made it possible for empty string to sneak into a "GEOMETRY NOT NULL" column when this column does not have a corresponding XML tag with data. After this patch the result of reset() is tested and and an error is returned in such cases. This change effectively resembles the patch for Bug#22372 3. Spliting the code into a new virtual method Field::load_data_set_null(). Rationale: a. To avoid duplicate code in read_sep_field() and read_xml_field(): Changes #1 and #2 made the code handling NULL values for Field exactly the same in read_sep_field() and read_xml_field(). b. To avoid tests for field_type(), which is not friendly to upcoming data type plugins. This change makes it possible for data type plugins to implement their own special way for handling NULL values in LOAD DATA by overriding Field_xxx::load_data_set_null(), like Field_geom and Field_timestamp do.

================== WARNING: ThreadSanitizer: data race (pid=12041) Write of size 8 at 0x000003949278 by thread T26 (mutexes: write M226445748578513120): #0 thd_destructor_proxy storage/innobase/handler/ha_innodb.cc:314:14 (mysqld+0x19b5505) Previous read of size 8 at 0x000003949278 by main thread: #0 innobase_init(void*) storage/innobase/handler/ha_innodb.cc:4180:11 (mysqld+0x1a03404) #1 ha_initialize_handlerton(st_plugin_int*) sql/handler.cc:522:31 (mysqld+0xc5ec73) #2 plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) sql/sql_plugin.cc:1447:9 (mysqld+0x134908d) #3 plugin_init(int*, char**, int) sql/sql_plugin.cc:1729:15 (mysqld+0x13484f0) #4 init_server_components() sql/mysqld.cc:5345:7 (mysqld+0xbf720f) #5 mysqld_main(int, char**) sql/mysqld.cc:5940:7 (mysqld+0xbf107d) #6 main sql/main.cc:25:10 (mysqld+0xbe971b) Location is global 'srv_running' of size 8 at 0x000003949278 (mysqld+0x000003949278) Mutex M226445748578513120 is already destroyed. Thread T26 (tid=12070, running) created by main thread at: #0 pthread_create /home/kevg/fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:992 (mysqld+0xb7a016) #1 spawn_thread_noop mysys/psi_noop.c:187:10 (mysqld+0x26fe403) #2 inline_mysql_thread_create(unsigned int, unsigned long*, pthread_attr_t const*, void* (*)(void*), void*) include/mysql/psi/mysql_thread.h:1239:11 (mysqld+0x1a1136d) #3 innobase_init(void*) storage/innobase/handler/ha_innodb.cc:4177:3 (mysqld+0x1a033e5) #4 ha_initialize_handlerton(st_plugin_int*) sql/handler.cc:522:31 (mysqld+0xc5ec73) #5 plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) sql/sql_plugin.cc:1447:9 (mysqld+0x134908d) #6 plugin_init(int*, char**, int) sql/sql_plugin.cc:1729:15 (mysqld+0x13484f0) #7 init_server_components() sql/mysqld.cc:5345:7 (mysqld+0xbf720f) #8 mysqld_main(int, char**) sql/mysqld.cc:5940:7 (mysqld+0xbf107d) #9 main sql/main.cc:25:10 (mysqld+0xbe971b) SUMMARY: ThreadSanitizer: data race storage/innobase/handler/ha_innodb.cc:314:14 in thd_destructor_proxy ==================

WARNING: ThreadSanitizer: data race (pid=27869) Atomic write of size 4 at 0x7b4800000c00 by thread T8: #0 __tsan_atomic32_exchange llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cc:589 (mysqld+0xbd4eac) #1 TTASEventMutex<GenericPolicy>::exit() storage/innobase/include/ib0mutex.h:467:7 (mysqld+0x1a8d4cb) #2 PolicyMutex<TTASEventMutex<GenericPolicy> >::exit() storage/innobase/include/ib0mutex.h:609:10 (mysqld+0x1a7839e) #3 fil_validate() storage/innobase/fil/fil0fil.cc:5535:2 (mysqld+0x1abd913) #4 fil_validate_skip() storage/innobase/fil/fil0fil.cc:204:9 (mysqld+0x1aba601) #5 fil_aio_wait(unsigned long) storage/innobase/fil/fil0fil.cc:5296:2 (mysqld+0x1abbae6) #6 io_handler_thread storage/innobase/srv/srv0start.cc:340:3 (mysqld+0x21abe1e) Previous read of size 4 at 0x7b4800000c00 by main thread (mutexes: write M1273, write M1271): #0 TTASEventMutex<GenericPolicy>::state() const storage/innobase/include/ib0mutex.h:530:10 (mysqld+0x21c66e2) #1 sync_array_detect_deadlock(sync_array_t*, sync_cell_t*, sync_cell_t*, unsigned long) storage/innobase/sync/sync0arr.cc:746:14 (mysqld+0x21c1c7a) #2 sync_array_wait_event(sync_array_t*, sync_cell_t*&) storage/innobase/sync/sync0arr.cc:465:6 (mysqld+0x21c1708) #3 TTASEventMutex<GenericPolicy>::enter(unsigned int, unsigned int, char const*, unsigned int) storage/innobase/include/ib0mutex.h:516:6 (mysqld+0x1a8c206) #4 PolicyMutex<TTASEventMutex<GenericPolicy> >::enter(unsigned int, unsigned int, char const*, unsigned int) storage/innobase/include/ib0mutex.h:635:10 (mysqld+0x1a782c3) #5 fil_mutex_enter_and_prepare_for_io(unsigned long) storage/innobase/fil/fil0fil.cc:1131:3 (mysqld+0x1a9a92e) #6 fil_io(IORequest const&, bool, page_id_t const&, page_size_t const&, unsigned long, unsigned long, void*, void*, bool) storage/innobase/fil/fil0fil.cc:5082:2 (mysqld+0x1ab8de2) #7 buf_flush_write_block_low(buf_page_t*, buf_flush_t, bool) storage/innobase/buf/buf0flu.cc:1112:3 (mysqld+0x1cb970a) #8 buf_flush_page(buf_pool_t*, buf_page_t*, buf_flush_t, bool) storage/innobase/buf/buf0flu.cc:1270:3 (mysqld+0x1cb7d70) #9 buf_flush_try_neighbors(page_id_t const&, buf_flush_t, unsigned long, unsigned long) storage/innobase/buf/buf0flu.cc:1493:9 (mysqld+0x1cc9674) #10 buf_flush_page_and_try_neighbors(buf_page_t*, buf_flush_t, unsigned long, unsigned long*) storage/innobase/buf/buf0flu.cc:1565:13 (mysqld+0x1cbadf3) #11 buf_do_flush_list_batch(buf_pool_t*, unsigned long, unsigned long) storage/innobase/buf/buf0flu.cc:1825:3 (mysqld+0x1cbbcb8) #12 buf_flush_batch(buf_pool_t*, buf_flush_t, unsigned long, unsigned long, flush_counters_t*) storage/innobase/buf/buf0flu.cc:1895:16 (mysqld+0x1cbb459) #13 buf_flush_do_batch(buf_pool_t*, buf_flush_t, unsigned long, unsigned long, flush_counters_t*) storage/innobase/buf/buf0flu.cc:2065:2 (mysqld+0x1cbcfe1) #14 buf_flush_lists(unsigned long, unsigned long, unsigned long*) storage/innobase/buf/buf0flu.cc:2167:8 (mysqld+0x1cbd5a3) #15 log_preflush_pool_modified_pages(unsigned long) storage/innobase/log/log0log.cc:1400:13 (mysqld+0x1eefc3b) #16 log_make_checkpoint_at(unsigned long, bool) storage/innobase/log/log0log.cc:1751:10 (mysqld+0x1eefb16) #17 buf_dblwr_create() storage/innobase/buf/buf0dblwr.cc:335:2 (mysqld+0x1cd2141) #18 innobase_start_or_create_for_mysql() storage/innobase/srv/srv0start.cc:2539:10 (mysqld+0x21b4d8e) #19 innobase_init(void*) storage/innobase/handler/ha_innodb.cc:4193:8 (mysqld+0x1a5e3d7) #20 ha_initialize_handlerton(st_plugin_int*) sql/handler.cc:522:31 (mysqld+0xc74d33) #21 plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) sql/sql_plugin.cc:1447:9 (mysqld+0x1376d5d) #22 plugin_init(int*, char**, int) sql/sql_plugin.cc:1729:15 (mysqld+0x13761c0) #23 init_server_components() sql/mysqld.cc:5348:7 (mysqld+0xc0d0ff) #24 mysqld_main(int, char**) sql/mysqld.cc:5943:7 (mysqld+0xc06f9d) #25 main sql/main.cc:25:10 (mysqld+0xbff71b)

srv_last_monitor_time: make all accesses relaxed atomical WARNING: ThreadSanitizer: data race (pid=29031) Write of size 8 at 0x0000039e48e0 by thread T15: #0 srv_monitor_thread storage/innobase/srv/srv0srv.cc:1699:24 (mysqld+0x21a254e) Previous write of size 8 at 0x0000039e48e0 by thread T14: #0 srv_refresh_innodb_monitor_stats() storage/innobase/srv/srv0srv.cc:1165:24 (mysqld+0x21a3124) #1 srv_error_monitor_thread storage/innobase/srv/srv0srv.cc:1836:3 (mysqld+0x21a2d40) Location is global 'srv_last_monitor_time' of size 8 at 0x0000039e48e0 (mysqld+0x0000039e48e0) Thread T15 (tid=29050, running) created by main thread at: #0 pthread_create /home/kevg/fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:992 (mysqld+0xb90016) #1 os_thread_create_func(void* (*)(void*), void*, unsigned long*) storage/innobase/os/os0thread.cc:137:12 (mysqld+0x1f50025) #2 innobase_start_or_create_for_mysql() storage/innobase/srv/srv0start.cc:2583:46 (mysqld+0x21b50b7) #3 innobase_init(void*) storage/innobase/handler/ha_innodb.cc:4193:8 (mysqld+0x1a5e3d7) #4 ha_initialize_handlerton(st_plugin_int*) sql/handler.cc:522:31 (mysqld+0xc74d33) #5 plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) sql/sql_plugin.cc:1447:9 (mysqld+0x1376d5d) #6 plugin_init(int*, char**, int) sql/sql_plugin.cc:1729:15 (mysqld+0x13761c0) #7 init_server_components() sql/mysqld.cc:5348:7 (mysqld+0xc0d0ff) #8 mysqld_main(int, char**) sql/mysqld.cc:5943:7 (mysqld+0xc06f9d) #9 main sql/main.cc:25:10 (mysqld+0xbff71b)

additionally fix data race which looks like this: WARNING: ThreadSanitizer: data race (pid=30515) Write of size 8 at 0x0000039ee908 by thread T21: #0 ib_counter_t<long, 64, counter_indexer_t>::add(unsigned long, long) storage/innobase/include/ut0counter.h:132:16 (mysqld+0x21cd166) #1 ib_counter_t<long, 64, counter_indexer_t>::add(long) storage/innobase/include/ut0counter.h:122:34 (mysqld+0x21cc102) #2 rw_lock_x_lock_wait_func(rw_lock_t*, unsigned long, long, char const*, unsigned int) storage/innobase/sync/sync0rw.cc:489:38 (mysqld+0x21cb91f) #3 rw_lock_x_lock_low(rw_lock_t*, unsigned long, char const*, unsigned int) storage/innobase/sync/sync0rw.cc:538:3 (mysqld+0x21c9339) #4 rw_lock_x_lock_func(rw_lock_t*, unsigned long, char const*, unsigned int) storage/innobase/sync/sync0rw.cc:698:6 (mysqld+0x21c8c4d) #5 pfs_rw_lock_x_lock_func(rw_lock_t*, unsigned long, char const*, unsigned int) storage/innobase/include/sync0rw.ic:568:3 (mysqld+0x1afbdb4) #6 buf_page_get_gen(page_id_t const&, page_size_t const&, unsigned long, buf_block_t*, unsigned long, char const*, unsigned int, mtr_t*, dberr_t*) storage/innobase/buf/buf0buf.cc:4782:3 (mysqld+0x1b04e28) #7 btr_cur_search_to_nth_level_func(dict_index_t*, unsigned long, dtuple_t const*, page_cur_mode_t, unsigned long, btr_cur_t*, rw_lock_t*, char const*, unsigned int, mtr_t*, unsigned long) storage/innobase/btr/btr0cur.cc:1312:10 (mysqld+0x1bf362c) #8 btr_pcur_open_low(dict_index_t*, unsigned long, dtuple_t const*, page_cur_mode_t, unsigned long, btr_pcur_t*, char const*, unsigned int, unsigned long, mtr_t*) storage/innobase/include/btr0pcur.ic:457:8 (mysqld+0x20eecd0) #9 row_search_on_row_ref(btr_pcur_t*, unsigned long, dict_table_t const*, dtuple_t const*, mtr_t*) storage/innobase/row/row0row.cc:1030:3 (mysqld+0x20ee1b4) #10 row_purge_reposition_pcur(unsigned long, purge_node_t*, mtr_t*) storage/innobase/row/row0purge.cc:103:23 (mysqld+0x20d7f6f) #11 row_purge_reset_trx_id(purge_node_t*, mtr_t*) storage/innobase/row/row0purge.cc:678:6 (mysqld+0x20dcbcd) #12 row_purge_record_func(purge_node_t*, unsigned char*, que_thr_t const*, bool) storage/innobase/row/row0purge.cc:1062:4 (mysqld+0x20db46f) #13 row_purge(purge_node_t*, unsigned char*, que_thr_t*) storage/innobase/row/row0purge.cc:1111:18 (mysqld+0x20d8aa4) #14 row_purge_step(que_thr_t*) storage/innobase/row/row0purge.cc:1190:3 (mysqld+0x20d872c) #15 que_thr_step(que_thr_t*) storage/innobase/que/que0que.cc:1055:9 (mysqld+0x1fcfa6f) #16 que_run_threads_low(que_thr_t*) storage/innobase/que/que0que.cc:1117:14 (mysqld+0x1fcdd6e) #17 que_run_threads(que_thr_t*) storage/innobase/que/que0que.cc:1157:2 (mysqld+0x1fcd908) #18 srv_task_execute() storage/innobase/srv/srv0srv.cc:2520:3 (mysqld+0x21a6684) #19 srv_worker_thread storage/innobase/srv/srv0srv.cc:2567:7 (mysqld+0x21a6247) Previous write of size 8 at 0x0000039ee908 by thread T20: #0 ib_counter_t<long, 64, counter_indexer_t>::add(unsigned long, long) storage/innobase/include/ut0counter.h:132:16 (mysqld+0x21cd166) #1 ib_counter_t<long, 64, counter_indexer_t>::add(long) storage/innobase/include/ut0counter.h:122:34 (mysqld+0x21cc102) #2 rw_lock_x_lock_wait_func(rw_lock_t*, unsigned long, long, char const*, unsigned int) storage/innobase/sync/sync0rw.cc:489:38 (mysqld+0x21cb91f) #3 rw_lock_x_lock_low(rw_lock_t*, unsigned long, char const*, unsigned int) storage/innobase/sync/sync0rw.cc:538:3 (mysqld+0x21c9339) #4 rw_lock_x_lock_func(rw_lock_t*, unsigned long, char const*, unsigned int) storage/innobase/sync/sync0rw.cc:698:6 (mysqld+0x21c8c4d) #5 pfs_rw_lock_x_lock_func(rw_lock_t*, unsigned long, char const*, unsigned int) storage/innobase/include/sync0rw.ic:568:3 (mysqld+0x1afbdb4) #6 buf_page_get_gen(page_id_t const&, page_size_t const&, unsigned long, buf_block_t*, unsigned long, char const*, unsigned int, mtr_t*, dberr_t*) storage/innobase/buf/buf0buf.cc:4782:3 (mysqld+0x1b04e28) #7 btr_cur_search_to_nth_level_func(dict_index_t*, unsigned long, dtuple_t const*, page_cur_mode_t, unsigned long, btr_cur_t*, rw_lock_t*, char const*, unsigned int, mtr_t*, unsigned long) storage/innobase/btr/btr0cur.cc:1312:10 (mysqld+0x1bf362c) #8 btr_pcur_open_low(dict_index_t*, unsigned long, dtuple_t const*, page_cur_mode_t, unsigned long, btr_pcur_t*, char const*, unsigned int, unsigned long, mtr_t*) storage/innobase/include/btr0pcur.ic:457:8 (mysqld+0x20eecd0) #9 row_search_on_row_ref(btr_pcur_t*, unsigned long, dict_table_t const*, dtuple_t const*, mtr_t*) storage/innobase/row/row0row.cc:1030:3 (mysqld+0x20ee1b4) #10 row_purge_reposition_pcur(unsigned long, purge_node_t*, mtr_t*) storage/innobase/row/row0purge.cc:103:23 (mysqld+0x20d7f6f) #11 row_purge_reset_trx_id(purge_node_t*, mtr_t*) storage/innobase/row/row0purge.cc:678:6 (mysqld+0x20dcbcd) #12 row_purge_record_func(purge_node_t*, unsigned char*, que_thr_t const*, bool) storage/innobase/row/row0purge.cc:1062:4 (mysqld+0x20db46f) #13 row_purge(purge_node_t*, unsigned char*, que_thr_t*) storage/innobase/row/row0purge.cc:1111:18 (mysqld+0x20d8aa4) #14 row_purge_step(que_thr_t*) storage/innobase/row/row0purge.cc:1190:3 (mysqld+0x20d872c) #15 que_thr_step(que_thr_t*) storage/innobase/que/que0que.cc:1055:9 (mysqld+0x1fcfa6f) #16 que_run_threads_low(que_thr_t*) storage/innobase/que/que0que.cc:1117:14 (mysqld+0x1fcdd6e) #17 que_run_threads(que_thr_t*) storage/innobase/que/que0que.cc:1157:2 (mysqld+0x1fcd908) #18 srv_task_execute() storage/innobase/srv/srv0srv.cc:2520:3 (mysqld+0x21a6684) #19 srv_worker_thread storage/innobase/srv/srv0srv.cc:2567:7 (mysqld+0x21a6247)

srv_last_monitor_time: make all accesses relaxed atomical WARNING: ThreadSanitizer: data race (pid=12041) Write of size 8 at 0x000003949278 by thread T26 (mutexes: write M226445748578513120): #0 thd_destructor_proxy storage/innobase/handler/ha_innodb.cc:314:14 (mysqld+0x19b5505) Previous read of size 8 at 0x000003949278 by main thread: #0 innobase_init(void*) storage/innobase/handler/ha_innodb.cc:4180:11 (mysqld+0x1a03404) #1 ha_initialize_handlerton(st_plugin_int*) sql/handler.cc:522:31 (mysqld+0xc5ec73) #2 plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) sql/sql_plugin.cc:1447:9 (mysqld+0x134908d) #3 plugin_init(int*, char**, int) sql/sql_plugin.cc:1729:15 (mysqld+0x13484f0) #4 init_server_components() sql/mysqld.cc:5345:7 (mysqld+0xbf720f) #5 mysqld_main(int, char**) sql/mysqld.cc:5940:7 (mysqld+0xbf107d) #6 main sql/main.cc:25:10 (mysqld+0xbe971b) Location is global 'srv_running' of size 8 at 0x000003949278 (mysqld+0x000003949278) WARNING: ThreadSanitizer: data race (pid=27869) Atomic write of size 4 at 0x7b4800000c00 by thread T8: #0 __tsan_atomic32_exchange llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cc:589 (mysqld+0xbd4eac) #1 TTASEventMutex<GenericPolicy>::exit() storage/innobase/include/ib0mutex.h:467:7 (mysqld+0x1a8d4cb) #2 PolicyMutex<TTASEventMutex<GenericPolicy> >::exit() storage/innobase/include/ib0mutex.h:609:10 (mysqld+0x1a7839e) #3 fil_validate() storage/innobase/fil/fil0fil.cc:5535:2 (mysqld+0x1abd913) #4 fil_validate_skip() storage/innobase/fil/fil0fil.cc:204:9 (mysqld+0x1aba601) #5 fil_aio_wait(unsigned long) storage/innobase/fil/fil0fil.cc:5296:2 (mysqld+0x1abbae6) #6 io_handler_thread storage/innobase/srv/srv0start.cc:340:3 (mysqld+0x21abe1e) Previous read of size 4 at 0x7b4800000c00 by main thread (mutexes: write M1273, write M1271): #0 TTASEventMutex<GenericPolicy>::state() const storage/innobase/include/ib0mutex.h:530:10 (mysqld+0x21c66e2) #1 sync_array_detect_deadlock(sync_array_t*, sync_cell_t*, sync_cell_t*, unsigned long) storage/innobase/sync/sync0arr.cc:746:14 (mysqld+0x21c1c7a) #2 sync_array_wait_event(sync_array_t*, sync_cell_t*&) storage/innobase/sync/sync0arr.cc:465:6 (mysqld+0x21c1708) #3 TTASEventMutex<GenericPolicy>::enter(unsigned int, unsigned int, char const*, unsigned int) storage/innobase/include/ib0mutex.h:516:6 (mysqld+0x1a8c206) #4 PolicyMutex<TTASEventMutex<GenericPolicy> >::enter(unsigned int, unsigned int, char const*, unsigned int) storage/innobase/include/ib0mutex.h:635:10 (mysqld+0x1a782c3) #5 fil_mutex_enter_and_prepare_for_io(unsigned long) storage/innobase/fil/fil0fil.cc:1131:3 (mysqld+0x1a9a92e) #6 fil_io(IORequest const&, bool, page_id_t const&, page_size_t const&, unsigned long, unsigned long, void*, void*, bool) storage/innobase/fil/fil0fil.cc:5082:2 (mysqld+0x1ab8de2) #7 buf_flush_write_block_low(buf_page_t*, buf_flush_t, bool) storage/innobase/buf/buf0flu.cc:1112:3 (mysqld+0x1cb970a) #8 buf_flush_page(buf_pool_t*, buf_page_t*, buf_flush_t, bool) storage/innobase/buf/buf0flu.cc:1270:3 (mysqld+0x1cb7d70) #9 buf_flush_try_neighbors(page_id_t const&, buf_flush_t, unsigned long, unsigned long) storage/innobase/buf/buf0flu.cc:1493:9 (mysqld+0x1cc9674) #10 buf_flush_page_and_try_neighbors(buf_page_t*, buf_flush_t, unsigned long, unsigned long*) storage/innobase/buf/buf0flu.cc:1565:13 (mysqld+0x1cbadf3) #11 buf_do_flush_list_batch(buf_pool_t*, unsigned long, unsigned long) storage/innobase/buf/buf0flu.cc:1825:3 (mysqld+0x1cbbcb8) #12 buf_flush_batch(buf_pool_t*, buf_flush_t, unsigned long, unsigned long, flush_counters_t*) storage/innobase/buf/buf0flu.cc:1895:16 (mysqld+0x1cbb459) #13 buf_flush_do_batch(buf_pool_t*, buf_flush_t, unsigned long, unsigned long, flush_counters_t*) storage/innobase/buf/buf0flu.cc:2065:2 (mysqld+0x1cbcfe1) #14 buf_flush_lists(unsigned long, unsigned long, unsigned long*) storage/innobase/buf/buf0flu.cc:2167:8 (mysqld+0x1cbd5a3) #15 log_preflush_pool_modified_pages(unsigned long) storage/innobase/log/log0log.cc:1400:13 (mysqld+0x1eefc3b) #16 log_make_checkpoint_at(unsigned long, bool) storage/innobase/log/log0log.cc:1751:10 (mysqld+0x1eefb16) #17 buf_dblwr_create() storage/innobase/buf/buf0dblwr.cc:335:2 (mysqld+0x1cd2141) #18 innobase_start_or_create_for_mysql() storage/innobase/srv/srv0start.cc:2539:10 (mysqld+0x21b4d8e) #19 innobase_init(void*) storage/innobase/handler/ha_innodb.cc:4193:8 (mysqld+0x1a5e3d7) #20 ha_initialize_handlerton(st_plugin_int*) sql/handler.cc:522:31 (mysqld+0xc74d33) #21 plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) sql/sql_plugin.cc:1447:9 (mysqld+0x1376d5d) #22 plugin_init(int*, char**, int) sql/sql_plugin.cc:1729:15 (mysqld+0x13761c0) #23 init_server_components() sql/mysqld.cc:5348:7 (mysqld+0xc0d0ff) #24 mysqld_main(int, char**) sql/mysqld.cc:5943:7 (mysqld+0xc06f9d) #25 main sql/main.cc:25:10 (mysqld+0xbff71b) WARNING: ThreadSanitizer: data race (pid=29031) Write of size 8 at 0x0000039e48e0 by thread T15: #0 srv_monitor_thread storage/innobase/srv/srv0srv.cc:1699:24 (mysqld+0x21a254e) Previous write of size 8 at 0x0000039e48e0 by thread T14: #0 srv_refresh_innodb_monitor_stats() storage/innobase/srv/srv0srv.cc:1165:24 (mysqld+0x21a3124) #1 srv_error_monitor_thread storage/innobase/srv/srv0srv.cc:1836:3 (mysqld+0x21a2d40) Location is global 'srv_last_monitor_time' of size 8 at 0x0000039e48e0 (mysqld+0x0000039e48e0)

Fixes this report: ==23122==ERROR: AddressSanitizer: use-after-poison on address 0x6190000d48d0 at pc 0x00000114c78c bp 0x7f97f40fb410 sp 0x7f97f40fabc0 WRITE of size 19 at 0x6190000d48d0 thread T27 #0 0x114c78b in __asan_memcpy fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:23 #1 0x2018dab in mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool, unsigned long long*, unsigned long long*) mariadb/sql/sql_update.cc:955:15 #2 0x1c33f1c in mysql_execute_command(THD*) mariadb/sql/sql_parse.cc:4550:21 #3 0x1c1da1c in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) mariadb/sql/sql_parse.cc:7980:18 #4 0x1c0f06e in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) mariadb/sql/sql_parse.cc:1824:7 #5 0x1c17fb4 in do_command(THD*) mariadb/sql/sql_parse.cc:1369:17 #6 0x21d1b10 in do_handle_one_connection(CONNECT*) mariadb/sql/sql_connect.cc:1402:11 #7 0x21d1211 in handle_one_connection mariadb/sql/sql_connect.cc:1308:3 #8 0x370ca14 in pfs_spawn_thread mariadb/storage/perfschema/pfs.cc:1862:3 #9 0x115b6ae in __asan::AsanThread::ThreadStart(unsigned long, __sanitizer::atomic_uintptr_t*) fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_thread.cc:259 #10 0x7f980d0aa7fb in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x77fb) #11 0x7f980aaceb5e in clone /build/glibc-itYbWN/glibc-2.26/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Fixes this report: ==3165==ERROR: AddressSanitizer: use-after-poison on address 0x61e0000270a0 at pc 0x00000114b78c bp 0x7f15d65fe120 sp 0x7f15d65fd8d0 WRITE of size 1366 at 0x61e0000270a0 thread T28 #0 0x114b78b in __asan_memcpy fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:23 #1 0x208208d in TABLE::init(THD*, TABLE_LIST*) work/mariadb/sql/table.cc:4662:3 #2 0x19df85b in open_table(THD*, TABLE_LIST*, Open_table_context*) work/mariadb/sql/sql_base.cc:1993:10 #3 0x19eb968 in open_and_process_table(THD*, LEX*, TABLE_LIST*, unsigned int*, unsigned int, Prelocking_strategy*, bool, Open_table_context*) work/mariadb/sql/sql_base.cc:3483:14 #4 0x19e7c05 in open_tables(THD*, DDL_options_st const&, TABLE_LIST**, unsigned int*, unsigned int, Prelocking_strategy*) work/mariadb/sql/sql_base.cc:4001:14 #5 0x19f4dac in open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*) work/mariadb/sql/sql_base.cc:4879:7 #6 0x1627263 in open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int) work/mariadb/sql/sql_base.h:487:10 #7 0x1c3839c in mysql_execute_command(THD*) work/mariadb/sql/sql_parse.cc:5113:13 #8 0x1c1b72c in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) work/mariadb/sql/sql_parse.cc:7980:18 #9 0x1c13464 in handle_bootstrap_impl(THD*) work/mariadb/sql/sql_parse.cc:1044:5 #10 0x1c11ff7 in do_handle_bootstrap(THD*) work/mariadb/sql/sql_parse.cc:1096:3 #11 0x1c11d14 in handle_bootstrap work/mariadb/sql/sql_parse.cc:1079:3 #12 0x115a6ae in __asan::AsanThread::ThreadStart(unsigned long, __sanitizer::atomic_uintptr_t*) fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_thread.cc:259 #13 0x7f15fe1407fb in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x77fb) #14 0x7f15fbb64b5e in clone /build/glibc-itYbWN/glibc-2.26/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95

srv_last_monitor_time: make all accesses relaxed atomical WARNING: ThreadSanitizer: data race (pid=12041) Write of size 8 at 0x000003949278 by thread T26 (mutexes: write M226445748578513120): #0 thd_destructor_proxy storage/innobase/handler/ha_innodb.cc:314:14 (mysqld+0x19b5505) Previous read of size 8 at 0x000003949278 by main thread: #0 innobase_init(void*) storage/innobase/handler/ha_innodb.cc:4180:11 (mysqld+0x1a03404) #1 ha_initialize_handlerton(st_plugin_int*) sql/handler.cc:522:31 (mysqld+0xc5ec73) #2 plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) sql/sql_plugin.cc:1447:9 (mysqld+0x134908d) #3 plugin_init(int*, char**, int) sql/sql_plugin.cc:1729:15 (mysqld+0x13484f0) #4 init_server_components() sql/mysqld.cc:5345:7 (mysqld+0xbf720f) #5 mysqld_main(int, char**) sql/mysqld.cc:5940:7 (mysqld+0xbf107d) #6 main sql/main.cc:25:10 (mysqld+0xbe971b) Location is global 'srv_running' of size 8 at 0x000003949278 (mysqld+0x000003949278) WARNING: ThreadSanitizer: data race (pid=27869) Atomic write of size 4 at 0x7b4800000c00 by thread T8: #0 __tsan_atomic32_exchange llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cc:589 (mysqld+0xbd4eac) #1 TTASEventMutex<GenericPolicy>::exit() storage/innobase/include/ib0mutex.h:467:7 (mysqld+0x1a8d4cb) #2 PolicyMutex<TTASEventMutex<GenericPolicy> >::exit() storage/innobase/include/ib0mutex.h:609:10 (mysqld+0x1a7839e) #3 fil_validate() storage/innobase/fil/fil0fil.cc:5535:2 (mysqld+0x1abd913) #4 fil_validate_skip() storage/innobase/fil/fil0fil.cc:204:9 (mysqld+0x1aba601) #5 fil_aio_wait(unsigned long) storage/innobase/fil/fil0fil.cc:5296:2 (mysqld+0x1abbae6) #6 io_handler_thread storage/innobase/srv/srv0start.cc:340:3 (mysqld+0x21abe1e) Previous read of size 4 at 0x7b4800000c00 by main thread (mutexes: write M1273, write M1271): #0 TTASEventMutex<GenericPolicy>::state() const storage/innobase/include/ib0mutex.h:530:10 (mysqld+0x21c66e2) #1 sync_array_detect_deadlock(sync_array_t*, sync_cell_t*, sync_cell_t*, unsigned long) storage/innobase/sync/sync0arr.cc:746:14 (mysqld+0x21c1c7a) #2 sync_array_wait_event(sync_array_t*, sync_cell_t*&) storage/innobase/sync/sync0arr.cc:465:6 (mysqld+0x21c1708) #3 TTASEventMutex<GenericPolicy>::enter(unsigned int, unsigned int, char const*, unsigned int) storage/innobase/include/ib0mutex.h:516:6 (mysqld+0x1a8c206) #4 PolicyMutex<TTASEventMutex<GenericPolicy> >::enter(unsigned int, unsigned int, char const*, unsigned int) storage/innobase/include/ib0mutex.h:635:10 (mysqld+0x1a782c3) #5 fil_mutex_enter_and_prepare_for_io(unsigned long) storage/innobase/fil/fil0fil.cc:1131:3 (mysqld+0x1a9a92e) #6 fil_io(IORequest const&, bool, page_id_t const&, page_size_t const&, unsigned long, unsigned long, void*, void*, bool) storage/innobase/fil/fil0fil.cc:5082:2 (mysqld+0x1ab8de2) #7 buf_flush_write_block_low(buf_page_t*, buf_flush_t, bool) storage/innobase/buf/buf0flu.cc:1112:3 (mysqld+0x1cb970a) #8 buf_flush_page(buf_pool_t*, buf_page_t*, buf_flush_t, bool) storage/innobase/buf/buf0flu.cc:1270:3 (mysqld+0x1cb7d70) #9 buf_flush_try_neighbors(page_id_t const&, buf_flush_t, unsigned long, unsigned long) storage/innobase/buf/buf0flu.cc:1493:9 (mysqld+0x1cc9674) #10 buf_flush_page_and_try_neighbors(buf_page_t*, buf_flush_t, unsigned long, unsigned long*) storage/innobase/buf/buf0flu.cc:1565:13 (mysqld+0x1cbadf3) #11 buf_do_flush_list_batch(buf_pool_t*, unsigned long, unsigned long) storage/innobase/buf/buf0flu.cc:1825:3 (mysqld+0x1cbbcb8) #12 buf_flush_batch(buf_pool_t*, buf_flush_t, unsigned long, unsigned long, flush_counters_t*) storage/innobase/buf/buf0flu.cc:1895:16 (mysqld+0x1cbb459) #13 buf_flush_do_batch(buf_pool_t*, buf_flush_t, unsigned long, unsigned long, flush_counters_t*) storage/innobase/buf/buf0flu.cc:2065:2 (mysqld+0x1cbcfe1) #14 buf_flush_lists(unsigned long, unsigned long, unsigned long*) storage/innobase/buf/buf0flu.cc:2167:8 (mysqld+0x1cbd5a3) #15 log_preflush_pool_modified_pages(unsigned long) storage/innobase/log/log0log.cc:1400:13 (mysqld+0x1eefc3b) #16 log_make_checkpoint_at(unsigned long, bool) storage/innobase/log/log0log.cc:1751:10 (mysqld+0x1eefb16) #17 buf_dblwr_create() storage/innobase/buf/buf0dblwr.cc:335:2 (mysqld+0x1cd2141) #18 innobase_start_or_create_for_mysql() storage/innobase/srv/srv0start.cc:2539:10 (mysqld+0x21b4d8e) #19 innobase_init(void*) storage/innobase/handler/ha_innodb.cc:4193:8 (mysqld+0x1a5e3d7) #20 ha_initialize_handlerton(st_plugin_int*) sql/handler.cc:522:31 (mysqld+0xc74d33) #21 plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) sql/sql_plugin.cc:1447:9 (mysqld+0x1376d5d) #22 plugin_init(int*, char**, int) sql/sql_plugin.cc:1729:15 (mysqld+0x13761c0) #23 init_server_components() sql/mysqld.cc:5348:7 (mysqld+0xc0d0ff) #24 mysqld_main(int, char**) sql/mysqld.cc:5943:7 (mysqld+0xc06f9d) #25 main sql/main.cc:25:10 (mysqld+0xbff71b) WARNING: ThreadSanitizer: data race (pid=29031) Write of size 8 at 0x0000039e48e0 by thread T15: #0 srv_monitor_thread storage/innobase/srv/srv0srv.cc:1699:24 (mysqld+0x21a254e) Previous write of size 8 at 0x0000039e48e0 by thread T14: #0 srv_refresh_innodb_monitor_stats() storage/innobase/srv/srv0srv.cc:1165:24 (mysqld+0x21a3124) #1 srv_error_monitor_thread storage/innobase/srv/srv0srv.cc:1836:3 (mysqld+0x21a2d40) Location is global 'srv_last_monitor_time' of size 8 at 0x0000039e48e0 (mysqld+0x0000039e48e0)

Cherry-pick this fix from the upstream: commit 6ddedd8f1e0ddcbc24e8f9a005636c5463799ab7 Author: Sergei Petrunia <psergey@askmonty.org> Date: Tue Apr 10 11:43:01 2018 -0700 [mysql-5.6][PR] Issue MariaDB#802: MyRocks: Statement rollback doesnt work correctly for nesâ�¦ Summary: â�¦ted statements Variant #1: When the statement fails, we should roll back to the latest savepoint taken at the top level. Closes facebook/mysql-5.6#804 Differential Revision: D7509380 Pulled By: hermanlee fbshipit-source-id: 9a6f414

Close connection handler on connection failure. This fixes 14 failing tests in main suite under clang+ASAN build. ASAN repost looks like this: ================================================================= ==25495==ERROR: LeakSanitizer: detected memory leaks Direct leak of 146280 byte(s) in 115 object(s) allocated from: #0 0x4fba47 in calloc /fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:138 #1 0x5a7a02 in mysql_init /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:977:26 #2 0x570a7a in do_connect(st_command*) /work/mariadb/client/mysqltest.cc:6096:26 #3 0x584c39 in main /work/mariadb/client/mysqltest.cc:9321:9 #4 0x7fd15514db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 Indirect leak of 7065600 byte(s) in 115 object(s) allocated from: #0 0x4fb80f in __interceptor_malloc /fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:129 #1 0x637a83 in my_context_init /work/mariadb/libmariadb/libmariadb/ma_context.c:367:23 #2 0x59fd16 in mysql_optionsv /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:2738:9 #3 0x5bc1d4 in mysql_options /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:3242:10 #4 0x570b94 in do_connect(st_command*) /work/mariadb/client/mysqltest.cc:6103:7 #5 0x584c39 in main /work/mariadb/client/mysqltest.cc:9321:9 #6 0x7fd15514db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 Indirect leak of 940240 byte(s) in 115 object(s) allocated from: #0 0x4fb80f in __interceptor_malloc /fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:129 #1 0x64386e in ma_init_dynamic_array /work/mariadb/libmariadb/libmariadb/ma_array.c:49:31 #2 0x649ead in _hash_init /work/mariadb/libmariadb/libmariadb/ma_hash.c:52:7 #3 0x5a3080 in mysql_optionsv /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:2938:13 #4 0x5bc20c in mysql_options4 /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:3248:10 #5 0x56f63b in connect_n_handle_errors(st_command*, st_mysql*, char const*, char const*, char const*, char const*, int, char const*) /work/mariadb/client/mysqltest.cc:5874:3 #6 0x57146b in do_connect(st_command*) /work/mariadb/client/mysqltest.cc:6193:7 #7 0x584c39 in main /work/mariadb/client/mysqltest.cc:9321:9 #8 0x7fd15514db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310

Close connection handler on connection failure. This fixes 14 failing tests in main suite under clang+ASAN build. ASAN report for main.connect looks like this: ================================================================= ==25495==ERROR: LeakSanitizer: detected memory leaks Direct leak of 146280 byte(s) in 115 object(s) allocated from: #0 0x4fba47 in calloc /fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:138 #1 0x5a7a02 in mysql_init /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:977:26 #2 0x570a7a in do_connect(st_command*) /work/mariadb/client/mysqltest.cc:6096:26 #3 0x584c39 in main /work/mariadb/client/mysqltest.cc:9321:9 #4 0x7fd15514db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 Indirect leak of 7065600 byte(s) in 115 object(s) allocated from: #0 0x4fb80f in __interceptor_malloc /fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:129 #1 0x637a83 in my_context_init /work/mariadb/libmariadb/libmariadb/ma_context.c:367:23 #2 0x59fd16 in mysql_optionsv /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:2738:9 #3 0x5bc1d4 in mysql_options /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:3242:10 #4 0x570b94 in do_connect(st_command*) /work/mariadb/client/mysqltest.cc:6103:7 #5 0x584c39 in main /work/mariadb/client/mysqltest.cc:9321:9 #6 0x7fd15514db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 Indirect leak of 940240 byte(s) in 115 object(s) allocated from: #0 0x4fb80f in __interceptor_malloc /fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:129 #1 0x64386e in ma_init_dynamic_array /work/mariadb/libmariadb/libmariadb/ma_array.c:49:31 #2 0x649ead in _hash_init /work/mariadb/libmariadb/libmariadb/ma_hash.c:52:7 #3 0x5a3080 in mysql_optionsv /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:2938:13 #4 0x5bc20c in mysql_options4 /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:3248:10 #5 0x56f63b in connect_n_handle_errors(st_command*, st_mysql*, char const*, char const*, char const*, char const*, int, char const*) /work/mariadb/client/mysqltest.cc:5874:3 #6 0x57146b in do_connect(st_command*) /work/mariadb/client/mysqltest.cc:6193:7 #7 0x584c39 in main /work/mariadb/client/mysqltest.cc:9321:9 #8 0x7fd15514db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 ...

specific temporary errors The optimistic parallel slave's worker thread could face a run-time error due to the algorithm's specifics which allows for conflicts like the reported "Can't find record in 'table'". A typical stack is like {noformat} #0 handler::print_error (this=0x61c00008f8a0, error=149, errflag=0) at handler.cc:3650 #1 0x0000555555e95361 in write_record (thd=thd@entry=0x62a0000a2208, table=table@entry=0x61f00008ce88, info=info@entry=0x7fffdee356d0) at sql_insert.cc:1944 #2 0x0000555555ea7767 in mysql_insert (thd=thd@entry=0x62a0000a2208, table_list=0x61b00012ada0, fields=..., values_list=..., update_fields=..., update_values=..., duplic=<optimized out>, ignore=<optimized out>) at sql_insert.cc:1039 #3 0x0000555555efda90 in mysql_execute_command (thd=thd@entry=0x62a0000a2208) at sql_parse.cc:3927 #4 0x0000555555f0cc50 in mysql_parse (thd=0x62a0000a2208, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at sql_parse.cc:7449 #5 0x00005555566d4444 in Query_log_event::do_apply_event (this=0x61200005b9c8, rgi=<optimized out>, query_arg=<optimized out>, q_len_arg=<optimized out>) at log_event.cc:4508 #6 0x00005555566d639e in Query_log_event::do_apply_event (this=<optimized out>, rgi=<optimized out>) at log_event.cc:4185 #7 0x0000555555d738cf in Log_event::apply_event (rgi=0x61d0001ea080, this=0x61200005b9c8) at log_event.h:1343 #8 apply_event_and_update_pos_apply (ev=ev@entry=0x61200005b9c8, thd=thd@entry=0x62a0000a2208, rgi=rgi@entry=0x61d0001ea080, reason=<optimized out>) at slave.cc:3479 #9 0x0000555555d8596b in apply_event_and_update_pos_for_parallel (ev=ev@entry=0x61200005b9c8, thd=thd@entry=0x62a0000a2208, rgi=rgi@entry=0x61d0001ea080) at slave.cc:3623 #10 0x00005555562aca83 in rpt_handle_event (qev=qev@entry=0x6190000fa088, rpt=rpt@entry=0x62200002bd68) at rpl_parallel.cc:50 #11 0x00005555562bd04e in handle_rpl_parallel_thread (arg=arg@entry=0x62200002bd68) at rpl_parallel.cc:1258 {noformat} Here {{handler::print_error}} computes whether to error log the current error when --log-warnings > 1. The decision flag is consulted bu {{my_message_sql()}} which can be eventually called. In the bug case the decision is to log. However in the optimistic mode slave applier case any conflict is attempted to resolve with rollback and retry to success. Hence the logging is at least extraneous. The case is fixed with adding a new flag {{ME_LOG_AS_WARN}} which {{handler::print_error}} may propagate further on through {{my_error}} when the error comes from an optimistically running slave worker thread. The new flag effectively requests the warning level for the errlog record, while the thread's DA records the actual error (which is regarded as temporary one by the parallel slave error handler).

This problem is similar to MDEV-10306. 1. Fixing Item_str_conv::val_str(String *str) to return the result in "str", and to use tmp_value only as a temporary buffer for args[0]->val_str(). The new code version now guarantees that the result is always returned in "str". The trick with copy_if_not_alloced() is not used any more. 2. The change #1 revealed the same problem in SUBSTRING_INDEX(), so some tests with combinations of UPPER()/LOWER() and SUBSTRING_INDEX() started to fail. Fixing Item_func_substr_index::val_str() the same way, to return the result in "str" and use tmp_value as a temporary buffer for args[0]->val_str().

…ARY INCONSISTENCY The server crashes on a SELECT because of space id mismatch. The mismatch happens if the server crashes during an ALTER TABLE. There are actually two cases of inconsistency, and three fixes needed for the InnoDB problems. We have dictionary data (tablespace or table name) in 3 places: (a) The *.frm file is for the old table definition. (b) The InnoDB data dictionary is for the new table definition. (c) The file system did not rename the tablespace files yet. In this fix, we will not care if the *.frm file is in sync with the InnoDB data dictionary and file system. We will concentrate on the mismatch between (b) and (c). Two scenarios have been mentioned in this bug report. The simpler one first: 1. The changes to SYS_TABLES were committed, and MLOG_FILE_RENAME2 records were written in a single mini-transaction commit. The files were not yet renamed in the file system. 2a. The server is killed, without making a log checkpoint. 3a. The server refuses to start up, because replaying MLOG_FILE_RENAME2 fails. I failed to repeat this myself. I repeated step 3a with a saved dataset. The problem seems to be that MLOG_FILE_RENAME2 replay is incorrectly being skipped when there is no page-redo log or MLOG_FILE_NAME record for the old name of the tablespace. FIX#1: Recover the id-to-name mapping also from MLOG_FILE_RENAME2 records when scanning the redo log. It is not necessary to write MLOG_FILE_NAME records in addition to MLOG_FILE_RENAME2 records for renaming tablespace files. The scenario in the original Description involves a log checkpoint: 1. The changes to SYS_TABLES were committed, and MLOG_FILE_RENAME2 records were written in a single mini-transaction commit. 2. A log checkpoint and a server kill was injected. 3. Crash recovery will see no records (other than the MLOG_CHECKPOINT). 4. dict_check_tablespaces_and_store_max_id() will emit a message about a non-found table #sql-ib22*. 5. A mismatch is triggering the assertion failure. In my test, at step 4 the SYS_TABLES root page (0:8) contains these 3 records right before the page supremum: * delete-marked (committed) name=#sql-ib21* record, with space=10. * name=#sql-ib22*, space=9. * name=t1, space=10. space=10 is the rebuilt table (#sql-ib21*.ibd in the file system). space=9 is the old table (t1.ibd in the file system). The function dict_check_tablespaces_and_store_max_id() will enter t1.ibd with space_id=10 into the fil_system cache without noticing that t1.ibd contains space_id=9, because it invokes fil_open_single_table_tablespace() with validate=false. In MySQL 5.6, the space_id from all *.ibd files are being read when the redo log checkpoint LSN disagrees with the FIL_PAGE_FILE_FLUSH_LSN in the system tablespace. This field is only updated during a clean shutdown, after performing the final log checkpoint. FIX#2: dict_check_tablespaces_and_store_max_id() should pass validate=true to fil_open_single_table_tablespace() when a non-clean shutdown is detected, forcing the first page of each *.ibd file to be read. (We do not want to slow down startup after a normal shutdown.) With FIX#2, the SELECT would fail to find the table. This would introduce a regression, because before WL#7142, a copy of the table was accessible after recovery. FIX#3: Maintain a list of MLOG_FILE_RENAME2 records that have been written to the redo log, but not performed yet in the file system. When performing a checkpoint, re-emit these records to the redo log. In this way, a mismatch between (b) and (c) should be impossible. fil_name_process(): Refactored from fil_name_parse(). Adds an item to the id-to-filename mapping. fil_name_parse(): Parses and applies a MLOG_FILE_NAME, MLOG_FILE_DELETE or MLOG_FILE_RENAME2 record. This implements FIX#1. fil_name_write_rename(): A wrapper function for writing MLOG_FILE_RENAME2 records. fil_op_replay_rename(): Apply MLOG_FILE_RENAME2 records. Replaces fil_op_log_parse_or_replay(), whose logic was moved to fil_name_parse(). fil_tablespace_exists_in_mem(): Return fil_space_t* instead of bool. dict_check_tablespaces_and_store_max_id(): Add the parameter "validate" to implement FIX#2. log_sys->append_on_checkpoint: Extra log records to append in case of a checkpoint. Needed for FIX#3. log_append_on_checkpoint(): New function, to update log_sys->append_on_checkpoint. mtr_write_log(): New function, to append mtr_buf_t to the redo log. fil_names_clear(): Append the data from log_sys->append_on_checkpoint if needed. ha_innobase::commit_inplace_alter_table(): Add any MLOG_FILE_RENAME2 records to log_sys->append_on_checkpoint(), and remove them once the files have been renamed in the file system. mtr_buf_copy_t: A helper functor for copying a mini-transaction log. rb#6282 approved by Jimmy Yang

Close connection handler on connection failure. This fixes 14 failing tests in main suite under clang+ASAN build. ASAN report for main.connect looks like this: ================================================================= ==25495==ERROR: LeakSanitizer: detected memory leaks Direct leak of 146280 byte(s) in 115 object(s) allocated from: #0 0x4fba47 in calloc /fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:138 #1 0x5a7a02 in mysql_init /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:977:26 #2 0x570a7a in do_connect(st_command*) /work/mariadb/client/mysqltest.cc:6096:26 #3 0x584c39 in main /work/mariadb/client/mysqltest.cc:9321:9 #4 0x7fd15514db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 Indirect leak of 7065600 byte(s) in 115 object(s) allocated from: #0 0x4fb80f in __interceptor_malloc /fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:129 #1 0x637a83 in my_context_init /work/mariadb/libmariadb/libmariadb/ma_context.c:367:23 #2 0x59fd16 in mysql_optionsv /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:2738:9 #3 0x5bc1d4 in mysql_options /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:3242:10 #4 0x570b94 in do_connect(st_command*) /work/mariadb/client/mysqltest.cc:6103:7 #5 0x584c39 in main /work/mariadb/client/mysqltest.cc:9321:9 #6 0x7fd15514db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 Indirect leak of 940240 byte(s) in 115 object(s) allocated from: #0 0x4fb80f in __interceptor_malloc /fun/cpp_projects/llvm_toolchain/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:129 #1 0x64386e in ma_init_dynamic_array /work/mariadb/libmariadb/libmariadb/ma_array.c:49:31 #2 0x649ead in _hash_init /work/mariadb/libmariadb/libmariadb/ma_hash.c:52:7 #3 0x5a3080 in mysql_optionsv /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:2938:13 #4 0x5bc20c in mysql_options4 /work/mariadb/libmariadb/libmariadb/mariadb_lib.c:3248:10 #5 0x56f63b in connect_n_handle_errors(st_command*, st_mysql*, char const*, char const*, char const*, char const*, int, char const*) /work/mariadb/client/mysqltest.cc:5874:3 #6 0x57146b in do_connect(st_command*) /work/mariadb/client/mysqltest.cc:6193:7 #7 0x584c39 in main /work/mariadb/client/mysqltest.cc:9321:9 #8 0x7fd15514db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 ... Closes MariaDB#809

Problem: ======== The mysqlbinlog tool is leaking memory, causing failures in various tests when compiling and testing with AddressSanitizer or LeakSanitizer like this: cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_ASAN:BOOL=ON /path/to/source make -j$(nproc) cd mysql-test ASAN_OPTIONS=abort_on_error=1 ./mtr --parallel=auto rpl.rpl_row_mysqlbinlog CURRENT_TEST: rpl.rpl_row_mysqlbinlog Direct leak of 112 byte(s) in 1 object(s) allocated from: #0 0x4eff87 in __interceptor_malloc (/dev/shm/5.5/client/mysqlbinlog+0x4eff87) #1 0x60eaab in my_malloc /mariadb/5.5/mysys/my_malloc.c:41:10 #2 0x5300dd in Log_event::read_log_event(char const*, unsigned int, char const**, Format_description_log_event const*, char) /mariadb/5.5/sql/log_event.cc:1568: #3 0x564a9c in dump_remote_log_entries(st_print_event_info*, char const*) /mariadb/5.5/client/mysqlbinlog.cc:1978:17 Analysis: ======== 'mysqlbinlog' tool is being used to read binary log events from a remote server. While reading binary log, if a fake rotate event is found following actions are taken. If 'to-last-log' option is specified, then fake rotate event is processed. In the absence of 'to-last-log' skip the fake rotate event. In this skipped case the fake rotate event object is not getting cleaned up resulting in memory leak. Fix: === Cleanup the fake rotate event. This issues is already fixed in MariaDB 10.0.23 and higher versions as part of commit c3018b0

…t operations with sequence The issue is that two MARIA_HA instances shares the same MARIA_STATUS_INFO object during UNION execution, so the second MARIA_HA instance state pointer MARIA_HA::state points to the MARIA_HA::state_save of the first MARIA instance. This happens in thr_multi_lock(...) { ... for (first_lock=data, pos= data+1 ; pos < end ; pos++) { ... if (pos[0]->lock == pos[-1]->lock && pos[0]->lock->copy_status) (pos[0]->lock->copy_status)((*pos)->status_param, (*first_lock)->status_param); ... } ... } Usually the state is restored from ha_maria::external_lock(...): \#0 _ma_update_status (param=0x6290000e6270) at ./storage/maria/ma_state.c:309 \#1 0x00005555577ccb15 in _ma_update_status_with_lock (info=0x6290000e6270) at ./storage/maria/ma_state.c:361 \#2 0x00005555577c7dcc in maria_lock_database (info=0x6290000e6270, lock_type=2) at ./storage/maria/ma_locking.c:66 \#3 0x0000555557802ccd in ha_maria::external_lock (this=0x61d0001b1308, thd=0x62a000048270, lock_type=2) at ./storage/maria/ha_maria.cc:2727 But _ma_update_status() does not take into account the case when MARIA_HA::status points to the MARIA_HA::state_save of the other MARIA_HA instance. The fix is to restore MARIA_HA::state in ha_maria::external_lock() after maria_lock_database() call for transactional tables.

Fix wrong typecast

…warning in case it is executed in PS (prepared statement) mode The EXPLAIN EXTENDED statement run as a prepared statement can produce extra warning comparing with a case when EXPLAIN EXTENDED statement is run as a regular statement. For example, the following test case CREATE TABLE t1 (c int); CREATE TABLE t2 (d int); EXPLAIN EXTENDED SELECT (SELECT 1 FROM t2 WHERE d = c) FROM t1; produces the extra warning "Field or reference 'c' of SELECT #2 was resolved in SELECT #1" in case the above mentioned "EXPLAIN EXTENDED" statement is executed in PS mode, that is by submitting the following statements: PREPARE stmt FROM "EXPLAIN EXTENDED SELECT (SELECT 1 FROM t2 WHERE d = c) FROM t1"; EXECUTE stmt; The reason of the extra warning emittion is in a way items are handled (being fixed) during execution of the JOIN::prepare() method. The method Item_field::fix_fields() calls the find_field_in_tables() function in case a field hasn't been associated yet with the item. Implementation of the find_field_in_tables() function first checks whether a table containing the required field was already opened and cached. It is done by checking the data member item->cached_table. This data member is set on handling the PRERARE FROM statement and checked on executing the EXECUTE statement. If the data member item->cached_table is set the find_field_in_tables() function invoked and the mark_select_range_as_dependent() function called if the field is an outer referencee. The mark_select_range_as_dependent() function calls the mark_as_dependent() function that finally invokes the push_warning_printf() function that produces extra warning. To fix the issue, calling of push_warning_printf() is elimited in case it was run indirectly in result of hanlding already opened table from the Item_field::fix_fields() method.

avodaniel added the bug label Sep 6, 2016

midenok self-assigned this Sep 6, 2016

midenok changed the title ~~Server segfaults when running prepared statetment for versioned tables~~ Server segfaults when running prepared statement for versioned tables Sep 6, 2016

midenok added a commit that referenced this issue Sep 6, 2016

Fix #1: segfault on prepared statement for versioned tables

d0d4d8e

midenok assigned avodaniel Sep 6, 2016

avodaniel closed this as completed Sep 7, 2016

midenok added the info label Sep 22, 2016

kevgs mentioned this issue Sep 26, 2016

Assertion failure on test 'insert' #25

Closed

midenok added segfault and removed bug labels Oct 4, 2016

midenok mentioned this issue Oct 4, 2016

Segfault in Item_cond on multiple execute of prepared statement #36

Closed

midenok added a commit that referenced this issue Oct 24, 2016

Fix #1: segfault on prepared statement for versioned tables

3d44be3

midenok added a commit that referenced this issue Oct 25, 2016

Fix #1: segfault on prepared statement for versioned tables

e53e801

midenok added a commit that referenced this issue Oct 25, 2016

Fix #1: segfault on prepared statement for versioned tables

bfd3ed6

midenok added a commit that referenced this issue Oct 27, 2016

Fix #1: segfault on prepared statement for versioned tables

7db8a30

midenok added a commit that referenced this issue Oct 28, 2016

Fix #1: segfault on prepared statement for versioned tables

05e664a

midenok added a commit that referenced this issue Oct 28, 2016

Fix #1: segfault on prepared statement for versioned tables

5a2148e

kevgs pushed a commit that referenced this issue Dec 28, 2016

Fix #1: segfault on prepared statement for versioned tables

da65774

kevgs pushed a commit that referenced this issue Dec 28, 2016

Fix #1: segfault on prepared statement for versioned tables

9916f42

kevgs pushed a commit that referenced this issue Dec 28, 2016

Fix #1: segfault on prepared statement for versioned tables

45580a6

kevgs pushed a commit that referenced this issue Dec 28, 2016

Fix #1: segfault on prepared statement for versioned tables

bd797fa

kevgs pushed a commit that referenced this issue Dec 30, 2016

Fix #1: segfault on prepared statement for versioned tables

1ce6409

kevgs pushed a commit that referenced this issue Jan 4, 2017

Fix #1: segfault on prepared statement for versioned tables

0c51f46

midenok pushed a commit that referenced this issue Jan 4, 2018

Better comments part #1

e27e7ec

midenok mentioned this issue Jun 17, 2018

MDEV-16372 ER_BASE64_DECODE_ERROR upon replaying binary log with system table #500

Closed

midenok pushed a commit that referenced this issue Sep 10, 2018

MyRocks: Post-merge testcase fixes part #1

a01823a

FooBarrior mentioned this issue Feb 26, 2019

MDEV-18432 RBR logging of system versioned tables #578

Closed

6 tasks

midenok pushed a commit that referenced this issue Apr 1, 2019

MDEV-19089 part #1: adapt rocksdb_stress suite for MariaDB

c2d9a34

midenok mentioned this issue May 25, 2019

MDEV-19597 Refactor TABLE::vers_update_fields() via stored virtual columns #379

Closed

i-rinat pushed a commit that referenced this issue May 20, 2020

MDEV-21341: Fix optimizer-related UBSAN failures, part #1:

0ac0bc8

Fix wrong typecast

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Server segfaults when running prepared statement for versioned tables #1

Server segfaults when running prepared statement for versioned tables #1

avodaniel commented Sep 6, 2016 •

edited by midenok

Loading

midenok commented Sep 6, 2016

midenok commented Sep 6, 2016 •

edited

Loading

midenok commented Sep 6, 2016 •

edited

Loading

midenok commented Sep 6, 2016 •

edited

Loading

midenok commented Sep 6, 2016

avodaniel commented Sep 7, 2016

midenok commented Sep 7, 2016

Server segfaults when running prepared statement for versioned tables #1

Server segfaults when running prepared statement for versioned tables #1

Comments

avodaniel commented Sep 6, 2016 • edited by midenok Loading

midenok commented Sep 6, 2016

midenok commented Sep 6, 2016 • edited Loading

midenok commented Sep 6, 2016 • edited Loading

midenok commented Sep 6, 2016 • edited Loading

Initialized:

1. Item copied:

2. Item deleted:

3. Item accessed:

midenok commented Sep 6, 2016

avodaniel commented Sep 7, 2016

midenok commented Sep 7, 2016

avodaniel commented Sep 6, 2016 •

edited by midenok

Loading

midenok commented Sep 6, 2016 •

edited

Loading

midenok commented Sep 6, 2016 •

edited

Loading

midenok commented Sep 6, 2016 •

edited

Loading