bug: MTR(tianmu.primary_secondary_bit/tianmu.zerofill) crashed or failed.

[lujiashun]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Please confirm if bug report does NOT exists already ?

• I confirm there is no existing issue for this

Describe the problem

1 MTR zerofill

[ 58%] tianmu.zerofill                          w8 [ fail ]
        Test ended at 2023-01-12 03:51:50

CURRENT_TEST: tianmu.zerofill
mysqltest: At line 46: query 'alter table st4 MODIFY id int' failed: 6: An unknown system exception error caught.

The result from queries just before the failure was:
< snip >
val+1
8
create table st3 (id1 int,id2 int(5));
insert into st3 values (1,1);
alter table st3 modify id1 int zerofill;
alter table st3 modify id2 int(5) zerofill;
insert into st3 values (1,1234567);
select * from st3;
id1	id2
0000000001	00001
0000000001	1234567
CREATE TABLE st4(  
`id` int(11) unsigned zerofill NOT NULL AUTO_INCREMENT,  
`col2` varchar(20) NOT NULL, 
`year` year(4) DEFAULT NULL,  
`month` int(2) unsigned zerofill DEFAULT NULL,  
`day` int(2) unsigned zerofill DEFAULT NULL,
PRIMARY KEY (`id`)
);
insert into st4 values(1,'test',2021,12,12);
safe_process[26204]: Child process: 26205, exit: 1

2 tianmu.primary_secondary_bit crashed:

(gdb) bt
#0  Rows_log_event::column_information_to_conditions (this=0x7ffb0400f890, sql_statemens="SELECT * FROM `test`.`bit_test` WHERE ",
    prefix=" WHERE ") at /data/codebase/stonedb57/stonedb/sql/log_event_push_cond.cc:358
#1  0x0000555557cd887e in Rows_log_event::row_event_to_statement (this=0x7ffb0400f890, lex_str=...,
    sql_statement="SELECT * FROM `test`.`bit_test` WHERE ") at /data/codebase/stonedb57/stonedb/sql/log_event_push_cond.cc:422
#2  0x0000555557cd8b31 in Rows_log_event::can_push_down (this=0x7ffb0400f890)
    at /data/codebase/stonedb57/stonedb/sql/log_event_push_cond.cc:452
#3  0x0000555557c3036c in Rows_log_event::do_table_scan_and_update (this=0x7ffb0400f890, rli=0x55555c333180)
    at /data/codebase/stonedb57/stonedb/sql/log_event.cc:10857
#4  0x0000555557c3189e in Rows_log_event::do_apply_event (this=0x7ffb0400f890, rli=0x55555c333180)
    at /data/codebase/stonedb57/stonedb/sql/log_event.cc:11347
#5  0x0000555557c18378 in Log_event::apply_event (this=0x7ffb0400f890, rli=0x55555c333180)
    at /data/codebase/stonedb57/stonedb/sql/log_event.cc:3481
#6  0x0000555557c963a8 in apply_event_and_update_pos (ptr_ev=0x7ffff003f970, thd=0x7ffb04000bf0, rli=0x55555c333180)
    at /data/codebase/stonedb57/stonedb/sql/rpl_slave.cc:4790
#7  0x0000555557c97bad in exec_relay_log_event (thd=0x7ffb04000bf0, rli=0x55555c333180)
    at /data/codebase/stonedb57/stonedb/sql/rpl_slave.cc:5328
#8  0x0000555557c9ed5a in handle_slave_sql (arg=0x55555c4e21d0) at /data/codebase/stonedb57/stonedb/sql/rpl_slave.cc:7525
#9  0x0000555558216135 in pfs_spawn_thread (arg=0x7ffb08029790) at /data/codebase/stonedb57/stonedb/storage/perfschema/pfs.cc:2197
#10 0x00007ffff73e1609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007ffff71b5133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) p  0
$6 = 0
(gdb) f 0
#0  Rows_log_event::column_information_to_conditions (this=0x7ffb0400f890, sql_statemens="SELECT * FROM `test`.`bit_test` WHERE ",
    prefix=" WHERE ") at /data/codebase/stonedb57/stonedb/sql/log_event_push_cond.cc:358
358         m_table->s->key_info->key_part->field)
(gdb) list
353         use the field of the unique constraint as the push down condition
354       */
355       std::string key_field_name;
356       if(m_table->s->key_info &&
357         m_table->s->key_info->key_part &&
358         m_table->s->key_info->key_part->field)
359       {
360         key_field_name = m_table->s->key_info->key_part->field->field_name;
361       }
362       int cond_num = 0;
(gdb) p m_table->s->key_info
$7 = (KEY *) 0x7ffb04015920
(gdb) p *m_table->s->key_info
$8 = {
  key_length = 2408513791,
  flags = 10344644715844964096,
  actual_flags = 10344644715844964096,
  user_defined_key_parts = 2408550144,
  actual_key_parts = 2408550287,
  unused_key_parts = 255,
  usable_key_parts = 0,
  block_size = 0,
  algorithm = HA_KEY_ALG_UNDEF,
  {
    parser = 0x8f8f8f8f8f8f0000,
    parser_name = 0x8f8f8f8f8f8f0000
  },
  key_part = 0x8f8f8f8f8f8f8f00,
  name = 0x7ffb04015a08 "\020+qYUU",
  rec_per_key = 0x7ffb04015ab8,
  m_in_memory_estimate = 6.9522981299519673e-310,
  rec_per_key_float = 0x7ffb04015c18,
  handler = {
    bdb_return_if_eq = 67176944
  },
  table = 0x7ffb04010aa0,
  comment = {
    str = 0x0,
    length = 140716080716257
  }
}

Expected behavior

run MTR tianmu.primary_secondary_bit tianmu.zerofill

How To Reproduce

No response

Environment

/data/stonedb57/install/bin/mysqld Ver 5.7.36-StoneDB-debug for Linux on x86_64 (build-)
build information as follow:
Repository address: https://github.com/lujiashun/stonedb.git:stonedb-5.7-dev
Branch name: stonedb-5.7-dev
Last commit ID: 3fa2aab
Last commit time: Date: Tue Jan 10 02:57:51 2023 +0000
Build time: Date: Thu 12 Jan 2023 12:13:45 PM CST

Are you interested in submitting a PR to solve the problem?

• Yes, I will!

[lujiashun]

For MTR primary_secondary_bit:
in the backtrace, we can see that in 1803 memset(keyinfo, 0, n_length), keyinfo is not null, but keyinfo has not keyinfo actually, because n_length = 0; So in log_event_push_cond.cc, the code to decide the unique constraint should is not proper;

356       if(m_table->s->key_info &&
357         m_table->s->key_info->key_part &&
358         m_table->s->key_info->key_part->field)

BT

1805      key_part= reinterpret_cast<KEY_PART_INFO*>(keyinfo+keys);
(gdb) list
1800                            NULL))
1801        goto err;                                   /* purecov: inspected */
1802
1803      memset(keyinfo, 0, n_length);
1804      share->key_info= keyinfo;
1805      key_part= reinterpret_cast<KEY_PART_INFO*>(keyinfo+keys);
1806
1807      use_packed_keys=
1808        ha_check_storage_engine_flag(share->db_type(),
1809                                     HTON_SUPPORTS_PACKED_KEYS);
(gdb) p keyinfo
$4 = (KEY *) 0x7ffb040158d0
(gdb) p *keyinfo
$5 = {
  key_length = 2408550287,
  flags = 10344644715844964239,
  actual_flags = 10344644715844964239,
  user_defined_key_parts = 2408550287,
  actual_key_parts = 2408550287,
  unused_key_parts = 2408550287,
  usable_key_parts = 2408550287,
  block_size = 2408550287,
  algorithm = 2408550287,
  {
    parser = 0x8f8f8f8f8f8f8f8f,
    parser_name = 0x8f8f8f8f8f8f8f8f
  },
  key_part = 0x8f8f8f8f8f8f8f8f,
  name = 0x8f8f8f8f8f8f8f8f <error: Cannot access memory at address 0x8f8f8f8f8f8f8f8f>,
  rec_per_key = 0x8f8f8f8f8f8f8f8f,
  m_in_memory_estimate = -9.9261575707946013e-234,
  rec_per_key_float = 0x8f8f8f8f8f8f8f8f,
  handler = {
    bdb_return_if_eq = -1886417009
  },
  table = 0x8f8f8f8f8f8f8f8f,
  comment = {
    str = 0x8f8f8f8f8f8f8f8f <error: Cannot access memory at address 0x8f8f8f8f8f8f8f8f>,
    length = 10344644715844964239
  }
}
(gdb) p n_length
$6 = 0
(gdb) bt
#0  open_binary_frm (thd=0x7ffb04000bf0, share=0x7ffb04013100, head=0x7ffff003eaa0 "\376\001\t\033\003", file=67)
    at /data/codebase/stonedb57/stonedb/sql/table.cc:1805
#1  0x0000555557a7993f in open_table_def (thd=0x7ffb04000bf0, share=0x7ffb04013100, db_flags=8196)
    at /data/codebase/stonedb57/stonedb/sql/table.cc:811
#2  0x00005555578f3df0 in get_table_share (thd=0x7ffb04000bf0, table_list=0x7ffb0400f0b0, key=0x7ffb0400f475 "test", key_length=14,
    db_flags=8196, error=0x7ffff003ee60, hash_value=2658423195) at /data/codebase/stonedb57/stonedb/sql/sql_base.cc:760
#3  0x00005555578f42ec in get_table_share_with_discover (thd=0x7ffb04000bf0, table_list=0x7ffb0400f0b0, key=0x7ffb0400f475 "test",
    key_length=14, db_flags=8196, error=0x7ffff003ee60, hash_value=2658423195) at /data/codebase/stonedb57/stonedb/sql/sql_base.cc:878
#4  0x00005555578f9a40 in open_table (thd=0x7ffb04000bf0, table_list=0x7ffb0400f0b0, ot_ctx=0x7ffff003f460)
    at /data/codebase/stonedb57/stonedb/sql/sql_base.cc:3444
#5  0x00005555578fcec5 in open_and_process_table (thd=0x7ffb04000bf0, lex=0x7ffb04002f18, tables=0x7ffb0400f0b0, counter=0x7ffff003f4e4,
    flags=0, prelocking_strategy=0x7ffff003f560, has_prelocking_list=false, ot_ctx=0x7ffff003f460)
    at /data/codebase/stonedb57/stonedb/sql/sql_base.cc:5260
#6  0x00005555578fe181 in open_tables (thd=0x7ffb04000bf0, start=0x7ffff003f4d0, counter=0x7ffff003f4e4, flags=0,
    prelocking_strategy=0x7ffff003f560) at /data/codebase/stonedb57/stonedb/sql/sql_base.cc:5883
#7  0x00005555578ff47c in open_and_lock_tables (thd=0x7ffb04000bf0, tables=0x7ffb0400f0b0, flags=0, prelocking_strategy=0x7ffff003f560)
    at /data/codebase/stonedb57/stonedb/sql/sql_base.cc:6607
#8  0x00005555572151a5 in open_and_lock_tables (thd=0x7ffb04000bf0, tables=0x7ffb0400f0b0, flags=0)
    at /data/codebase/stonedb57/stonedb/sql/sql_base.h:487
#9  0x0000555557c30b4e in Rows_log_event::do_apply_event (this=0x7ffb0400f840, rli=0x55555c334260)
    at /data/codebase/stonedb57/stonedb/sql/log_event.cc:11024
#10 0x0000555557c18378 in Log_event::apply_event (this=0x7ffb0400f840, rli=0x55555c334260)
    at /data/codebase/stonedb57/stonedb/sql/log_event.cc:3481
#11 0x0000555557c963a8 in apply_event_and_update_pos (ptr_ev=0x7ffff003f970, thd=0x7ffb04000bf0, rli=0x55555c334260)
    at /data/codebase/stonedb57/stonedb/sql/rpl_slave.cc:4790
#12 0x0000555557c97bad in exec_relay_log_event (thd=0x7ffb04000bf0, rli=0x55555c334260)
    at /data/codebase/stonedb57/stonedb/sql/rpl_slave.cc:5328
#13 0x0000555557c9ed5a in handle_slave_sql (arg=0x55555c4e3290) at /data/codebase/stonedb57/stonedb/sql/rpl_slave.cc:7525
#14 0x0000555558216135 in pfs_spawn_thread (arg=0x7ffb08029790) at /data/codebase/stonedb57/stonedb/storage/perfschema/pfs.cc:2197
#15 0x00007ffff73e1609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#16 0x00007ffff71b5133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[lujiashun]

tianmu.zerofill is not always reproduced, only occurs once in the new PR,hard to say it is the original code reason.

[RingsC]

There is a way you can try it:
1: disable the exception, and let stonedb crash at which it produced. To debug this with its coredump. i think it is the easy way to identify the root cause.
2: To run MTR in debug mode. @lujiashun @konghaiya