Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23600

SIGFPE in row_search_with_covering_prefix

Details

    Description

      May be a GIS issue, though is in InnoDB frame (row_search_with_covering_prefix), please check source. Thank you

      USE test;
      SET SQL_MODE='';
      SET GLOBAL innodb_prefix_index_cluster_optimization=1;
      CREATE TABLE t(c POINT GENERATED ALWAYS AS (POINT(1,1)) UNIQUE) ENGINE=InnoDB;
      INSERT t SET c=1;
      INSERT INTO t SELECT * FROM t WHERE c > (SELECT MAX(c) FROM t);
      

      Leads to:

      10.5.6 1c587481966abc7a9ad5309d0a91ca920f7a5657 (Debug)

      Core was generated by `/test/MD110820-mariadb-10.5.6-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
      Program terminated with signal SIGFPE, Arithmetic exception.
      #0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=8)
          at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
      [Current thread is 1 (Thread 0x1469d6ea6700 (LWP 3630278))]
      (gdb) bt
      #0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=8) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
      #1  0x000055912a5b1b86 in my_write_core (sig=sig@entry=8) at /test/10.5_dbg/mysys/stacktrace.c:519
      #2  0x0000559129d68d7b in handle_fatal_signal (sig=8) at /test/10.5_dbg/sql/signal_handler.cc:330
      #3  <signal handler called>
      #4  0x000055912a2e93af in row_search_with_covering_prefix (offsets=0x1469d6ea3a40, rec=0x1469b9dbc07f "", prebuilt=0x1469b296d098) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:4122
      #5  row_search_mvcc (buf=buf@entry=0x1469b2857fa8 "\377", mode=PAGE_CUR_GE, prebuilt=0x1469b296d098, match_mode=<optimized out>, direction=direction@entry=0) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:5223
      #6  0x000055912a13960a in ha_innobase::index_read (this=0x1469b294f0a0, buf=0x1469b2857fa8 "\377", key_ptr=0x1469b2976150 "", key_len=28, find_flag=HA_READ_KEY_OR_NEXT) at /test/10.5_dbg/storage/innobase/handler/ha_innodb.cc:8788
      #7  0x0000559129d83db4 in handler::index_read_map (this=0x1469b294f0a0, buf=0x1469b2857fa8 "\377", key=0x1469b2976150 "", keypart_map=<optimized out>, find_flag=HA_READ_KEY_OR_NEXT) at /test/10.5_dbg/sql/handler.h:3798
      #8  0x0000559129d72001 in handler::ha_index_read_map (this=this@entry=0x1469b294f0a0, buf=0x1469b2857fa8 "\377", key=0x1469b2976150 "", keypart_map=1, find_flag=HA_READ_KEY_OR_NEXT) at /test/10.5_dbg/sql/handler.cc:3117
      #9  0x0000559129d7a320 in handler::read_range_first (this=0x1469b294f0a0, start_key=0x1469b294f1a0, end_key=0x0, eq_range_arg=<optimized out>, sorted=<optimized out>) at /test/10.5_dbg/sql/handler.cc:6182
      #10 0x0000559129c5a95b in handler::multi_range_read_next (this=0x1469b294f0a0, range_info=range_info@entry=0x1469d6ea47d8) at /test/10.5_dbg/sql/multi_range_read.cc:516
      #11 0x0000559129c5a9e6 in Mrr_simple_index_reader::get_next (this=0x1469b294f6d0, range_info=0x1469d6ea47d8) at /test/10.5_dbg/sql/multi_range_read.cc:553
      #12 0x0000559129c5c846 in DsMrr_impl::dsmrr_next (this=0x1469b294f580, range_info=0x1469d6ea47d8) at /test/10.5_dbg/sql/multi_range_read.cc:1653
      #13 0x000055912a11fe04 in ha_innobase::multi_range_read_next (this=<optimized out>, range_info=<optimized out>) at /test/10.5_dbg/storage/innobase/handler/ha_innodb.cc:20333
      #14 0x0000559129ee8c70 in QUICK_RANGE_SELECT::get_next (this=0x1469b2810100) at /test/10.5_dbg/sql/opt_range.cc:12247
      #15 0x0000559129f123c0 in rr_quick (info=0x1469b2971190) at /test/10.5_dbg/sql/records.cc:403
      #16 0x0000559129b117c2 in READ_RECORD::read_record (this=0x1469b2971190) at /test/10.5_dbg/sql/records.h:80
      #17 join_init_read_record (tab=0x1469b29710c8) at /test/10.5_dbg/sql/sql_select.cc:21569
      #18 0x0000559129b009f1 in sub_select (join=0x1469b2877aa8, join_tab=0x1469b29710c8, end_of_records=<optimized out>) at /test/10.5_dbg/sql/sql_select.cc:20621
      #19 0x0000559129b3ab32 in do_select (procedure=0x0, join=0x1469b2877aa8) at /test/10.5_dbg/sql/sql_select.cc:20158
      #20 JOIN::exec_inner (this=this@entry=0x1469b2877aa8) at /test/10.5_dbg/sql/sql_select.cc:4450
      #21 0x0000559129b3b14d in JOIN::exec (this=this@entry=0x1469b2877aa8) at /test/10.5_dbg/sql/sql_select.cc:4231
      #22 0x0000559129b39449 in mysql_select (thd=thd@entry=0x1469b2815088, tables=<optimized out>, fields=@0x1469b28749f0: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x1469b2874e50, last = 0x1469b2874e50, elements = 1}, <No data fields>}, conds=0x1469b2876f10, og_num=0, order=<optimized out>, group=0x0, having=0x0, proc_param=0x0, select_options=2202244745984, result=0x1469b28779f0, unit=0x1469b28190a0, select_lex=0x1469b28748a0) at /test/10.5_dbg/sql/sql_select.cc:4655
      #23 0x0000559129b39778 in handle_select (thd=thd@entry=0x1469b2815088, lex=lex@entry=0x1469b2818fd8, result=result@entry=0x1469b28779f0, setup_tables_done_option=setup_tables_done_option@entry=1073741824) at /test/10.5_dbg/sql/sql_select.cc:417
      #24 0x0000559129abceab in mysql_execute_command (thd=thd@entry=0x1469b2815088) at /test/10.5_dbg/sql/sql_parse.cc:4692
      #25 0x0000559129ac7d4e in mysql_parse (thd=thd@entry=0x1469b2815088, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1469d6ea5350, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:7994
      #26 0x0000559129ab477e in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x1469b2815088, packet=packet@entry=0x1469b2867089 "INSERT INTO t SELECT * FROM t WHERE c > (SELECT MAX(c) FROM t)", packet_length=packet_length@entry=62, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:1867
      #27 0x0000559129ab2f58 in do_command (thd=0x1469b2815088) at /test/10.5_dbg/sql/sql_parse.cc:1348
      #28 0x0000559129c0fbc9 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x1469b5cd0808, put_in_cache=put_in_cache@entry=true) at /test/10.5_dbg/sql/sql_connect.cc:1410
      #29 0x0000559129c102e5 in handle_one_connection (arg=arg@entry=0x1469b5cd0808) at /test/10.5_dbg/sql/sql_connect.cc:1312
      #30 0x000055912a076572 in pfs_spawn_thread (arg=0x1469d3c46508) at /test/10.5_dbg/storage/perfschema/pfs.cc:2201
      #31 0x00001469d5e1f6db in start_thread (arg=0x1469d6ea6700) at pthread_create.c:463
      #32 0x00001469d521da3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Bug confirmed present in:
      MariaDB: 10.2.34 (dbg), 10.2.34 (opt), 10.3.25 (dbg), 10.3.25 (opt), 10.4.15 (dbg), 10.4.15 (opt), 10.5.6 (dbg), 10.5.6 (opt)

      Bug confirmed not present in:
      MariaDB: 10.1.47 (dbg), 10.1.47 (opt)
      MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.47 (dbg), 5.6.47 (opt), 5.7.29 (dbg), 5.7.29 (opt), 8.0.19 (dbg), 8.0.19 (opt)

      10.1 Gives:

      10.1.47 (Debug)

      10.1.47>CREATE TABLE t(c POINT GENERATED ALWAYS AS (POINT(1,1)) UNIQUE) ENGINE=InnoDB;
      ERROR 1904 (HY000): Key/Index cannot be defined on a non-stored computed column
      

      Attachments

        Issue Links

          Activity

            Secondary testcase

            USE test;
            SET GLOBAL innodb_prefix_index_cluster_optimization = 1;
            CREATE TABLE t1(c INT, p POINT, KEY(p)) ENGINE=InnoDB;
            INSERT INTO t1 VALUES (103, ST_POINTFROMTEXT('POINT(1 1)'));
            SELECT ST_ASTEXT(p) FROM t1 WHERE p = ST_POINTFROMTEXT('POINT(1 1)');
            

            Leads to:

            10.5.6 1c587481966abc7a9ad5309d0a91ca920f7a5657 (Debug)

            Core was generated by `/test/MD110820-mariadb-10.5.6-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
            Program terminated with signal SIGFPE, Arithmetic exception.
            #0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=8)
                at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
            [Current thread is 1 (Thread 0x14825fac4700 (LWP 255769))]
            (gdb) bt
            #0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=8) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
            #1  0x000055c80e3f2b86 in my_write_core (sig=sig@entry=8) at /test/10.5_dbg/mysys/stacktrace.c:519
            #2  0x000055c80dba9d7b in handle_fatal_signal (sig=8) at /test/10.5_dbg/sql/signal_handler.cc:330
            #3  <signal handler called>
            #4  0x000055c80e12a3af in row_search_with_covering_prefix (offsets=0x14825fac1740, rec=0x1482429bc07f "", prebuilt=0x14823b0f0098) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:4122
            #5  row_search_mvcc (buf=buf@entry=0x14823b052aa8 <incomplete sequence \375>, mode=PAGE_CUR_GE, prebuilt=0x14823b0f0098, match_mode=<optimized out>, direction=direction@entry=0) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:5223
            #6  0x000055c80df7a60a in ha_innobase::index_read (this=0x14823b036ca0, buf=0x14823b052aa8 <incomplete sequence \375>, key_ptr=0x14823b078440 "", key_len=28, find_flag=HA_READ_KEY_EXACT) at /test/10.5_dbg/storage/innobase/handler/ha_innodb.cc:8788
            #7  0x000055c80dbc4db4 in handler::index_read_map (this=0x14823b036ca0, buf=0x14823b052aa8 <incomplete sequence \375>, key=0x14823b078440 "", keypart_map=<optimized out>, find_flag=HA_READ_KEY_EXACT) at /test/10.5_dbg/sql/handler.h:3798
            #8  0x000055c80dbb3001 in handler::ha_index_read_map (this=0x14823b036ca0, buf=0x14823b052aa8 <incomplete sequence \375>, key=0x14823b078440 "", keypart_map=1, find_flag=find_flag@entry=HA_READ_KEY_EXACT) at /test/10.5_dbg/sql/handler.cc:3117
            #9  0x000055c80d951a18 in join_read_always_key (tab=0x14823b077cd0) at /test/10.5_dbg/sql/sql_select.cc:21388
            #10 0x000055c80d9419f1 in sub_select (join=0x14823b075e10, join_tab=0x14823b077cd0, end_of_records=<optimized out>) at /test/10.5_dbg/sql/sql_select.cc:20621
            #11 0x000055c80d97bb32 in do_select (procedure=0x0, join=0x14823b075e10) at /test/10.5_dbg/sql/sql_select.cc:20158
            #12 JOIN::exec_inner (this=this@entry=0x14823b075e10) at /test/10.5_dbg/sql/sql_select.cc:4450
            #13 0x000055c80d97c14d in JOIN::exec (this=this@entry=0x14823b075e10) at /test/10.5_dbg/sql/sql_select.cc:4231
            #14 0x000055c80d97a449 in mysql_select (thd=thd@entry=0x14823b015088, tables=<optimized out>, fields=@0x14823b0742e0: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x14823b074868, last = 0x14823b074868, elements = 1}, <No data fields>}, conds=0x14823b0752b8, og_num=0, order=<optimized out>, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x14823b075de8, unit=0x14823b0190a0, select_lex=0x14823b074190) at /test/10.5_dbg/sql/sql_select.cc:4655
            #15 0x000055c80d97a778 in handle_select (thd=thd@entry=0x14823b015088, lex=lex@entry=0x14823b018fd8, result=result@entry=0x14823b075de8, setup_tables_done_option=setup_tables_done_option@entry=0) at /test/10.5_dbg/sql/sql_select.cc:417
            #16 0x000055c80d902d72 in execute_sqlcom_select (thd=thd@entry=0x14823b015088, all_tables=0x14823b0748c0) at /test/10.5_dbg/sql/sql_parse.cc:6210
            #17 0x000055c80d8fbe46 in mysql_execute_command (thd=thd@entry=0x14823b015088) at /test/10.5_dbg/sql/sql_parse.cc:3932
            #18 0x000055c80d908d4e in mysql_parse (thd=thd@entry=0x14823b015088, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14825fac3350, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:7994
            #19 0x000055c80d8f577e in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14823b015088, packet=packet@entry=0x14823b067089 "", packet_length=packet_length@entry=68, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:1867
            #20 0x000055c80d8f3f58 in do_command (thd=0x14823b015088) at /test/10.5_dbg/sql/sql_parse.cc:1348
            #21 0x000055c80da50bc9 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x14823e8d0808, put_in_cache=put_in_cache@entry=true) at /test/10.5_dbg/sql/sql_connect.cc:1410
            #22 0x000055c80da512e5 in handle_one_connection (arg=arg@entry=0x14823e8d0808) at /test/10.5_dbg/sql/sql_connect.cc:1312
            #23 0x000055c80deb7572 in pfs_spawn_thread (arg=0x14825c846508) at /test/10.5_dbg/storage/perfschema/pfs.cc:2201
            #24 0x000014825ea3d6db in start_thread (arg=0x14825fac4700) at pthread_create.c:463
            #25 0x000014825de3ba3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
            

            Bug confirmed present in:
            MariaDB: 10.2.34 (dbg), 10.2.34 (opt), 10.3.25 (dbg), 10.3.25 (opt), 10.4.15 (dbg), 10.4.15 (opt), 10.5.6 (dbg), 10.5.6 (opt)

            Bug confirmed not present in:
            MariaDB: 10.1.47 (dbg), 10.1.47 (opt)
            MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.47 (dbg), 5.6.47 (opt), 5.7.29 (dbg), 5.7.29 (opt), 8.0.19 (dbg), 8.0.19 (opt)

            Roel Roel Van de Paar added a comment - Secondary testcase USE test; SET GLOBAL innodb_prefix_index_cluster_optimization = 1; CREATE TABLE t1(c INT, p POINT, KEY(p)) ENGINE=InnoDB; INSERT INTO t1 VALUES (103, ST_POINTFROMTEXT('POINT(1 1)')); SELECT ST_ASTEXT(p) FROM t1 WHERE p = ST_POINTFROMTEXT('POINT(1 1)'); Leads to: 10.5.6 1c587481966abc7a9ad5309d0a91ca920f7a5657 (Debug) Core was generated by `/test/MD110820-mariadb-10.5.6-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'. Program terminated with signal SIGFPE, Arithmetic exception. #0 __pthread_kill (threadid=<optimized out>, signo=signo@entry=8) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57 [Current thread is 1 (Thread 0x14825fac4700 (LWP 255769))] (gdb) bt #0 __pthread_kill (threadid=<optimized out>, signo=signo@entry=8) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57 #1 0x000055c80e3f2b86 in my_write_core (sig=sig@entry=8) at /test/10.5_dbg/mysys/stacktrace.c:519 #2 0x000055c80dba9d7b in handle_fatal_signal (sig=8) at /test/10.5_dbg/sql/signal_handler.cc:330 #3 <signal handler called> #4 0x000055c80e12a3af in row_search_with_covering_prefix (offsets=0x14825fac1740, rec=0x1482429bc07f "", prebuilt=0x14823b0f0098) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:4122 #5 row_search_mvcc (buf=buf@entry=0x14823b052aa8 <incomplete sequence \375>, mode=PAGE_CUR_GE, prebuilt=0x14823b0f0098, match_mode=<optimized out>, direction=direction@entry=0) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:5223 #6 0x000055c80df7a60a in ha_innobase::index_read (this=0x14823b036ca0, buf=0x14823b052aa8 <incomplete sequence \375>, key_ptr=0x14823b078440 "", key_len=28, find_flag=HA_READ_KEY_EXACT) at /test/10.5_dbg/storage/innobase/handler/ha_innodb.cc:8788 #7 0x000055c80dbc4db4 in handler::index_read_map (this=0x14823b036ca0, buf=0x14823b052aa8 <incomplete sequence \375>, key=0x14823b078440 "", keypart_map=<optimized out>, find_flag=HA_READ_KEY_EXACT) at /test/10.5_dbg/sql/handler.h:3798 #8 0x000055c80dbb3001 in handler::ha_index_read_map (this=0x14823b036ca0, buf=0x14823b052aa8 <incomplete sequence \375>, key=0x14823b078440 "", keypart_map=1, find_flag=find_flag@entry=HA_READ_KEY_EXACT) at /test/10.5_dbg/sql/handler.cc:3117 #9 0x000055c80d951a18 in join_read_always_key (tab=0x14823b077cd0) at /test/10.5_dbg/sql/sql_select.cc:21388 #10 0x000055c80d9419f1 in sub_select (join=0x14823b075e10, join_tab=0x14823b077cd0, end_of_records=<optimized out>) at /test/10.5_dbg/sql/sql_select.cc:20621 #11 0x000055c80d97bb32 in do_select (procedure=0x0, join=0x14823b075e10) at /test/10.5_dbg/sql/sql_select.cc:20158 #12 JOIN::exec_inner (this=this@entry=0x14823b075e10) at /test/10.5_dbg/sql/sql_select.cc:4450 #13 0x000055c80d97c14d in JOIN::exec (this=this@entry=0x14823b075e10) at /test/10.5_dbg/sql/sql_select.cc:4231 #14 0x000055c80d97a449 in mysql_select (thd=thd@entry=0x14823b015088, tables=<optimized out>, fields=@0x14823b0742e0: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x14823b074868, last = 0x14823b074868, elements = 1}, <No data fields>}, conds=0x14823b0752b8, og_num=0, order=<optimized out>, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x14823b075de8, unit=0x14823b0190a0, select_lex=0x14823b074190) at /test/10.5_dbg/sql/sql_select.cc:4655 #15 0x000055c80d97a778 in handle_select (thd=thd@entry=0x14823b015088, lex=lex@entry=0x14823b018fd8, result=result@entry=0x14823b075de8, setup_tables_done_option=setup_tables_done_option@entry=0) at /test/10.5_dbg/sql/sql_select.cc:417 #16 0x000055c80d902d72 in execute_sqlcom_select (thd=thd@entry=0x14823b015088, all_tables=0x14823b0748c0) at /test/10.5_dbg/sql/sql_parse.cc:6210 #17 0x000055c80d8fbe46 in mysql_execute_command (thd=thd@entry=0x14823b015088) at /test/10.5_dbg/sql/sql_parse.cc:3932 #18 0x000055c80d908d4e in mysql_parse (thd=thd@entry=0x14823b015088, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14825fac3350, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:7994 #19 0x000055c80d8f577e in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14823b015088, packet=packet@entry=0x14823b067089 "", packet_length=packet_length@entry=68, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:1867 #20 0x000055c80d8f3f58 in do_command (thd=0x14823b015088) at /test/10.5_dbg/sql/sql_parse.cc:1348 #21 0x000055c80da50bc9 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x14823e8d0808, put_in_cache=put_in_cache@entry=true) at /test/10.5_dbg/sql/sql_connect.cc:1410 #22 0x000055c80da512e5 in handle_one_connection (arg=arg@entry=0x14823e8d0808) at /test/10.5_dbg/sql/sql_connect.cc:1312 #23 0x000055c80deb7572 in pfs_spawn_thread (arg=0x14825c846508) at /test/10.5_dbg/storage/perfschema/pfs.cc:2201 #24 0x000014825ea3d6db in start_thread (arg=0x14825fac4700) at pthread_create.c:463 #25 0x000014825de3ba3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Bug confirmed present in: MariaDB: 10.2.34 (dbg), 10.2.34 (opt), 10.3.25 (dbg), 10.3.25 (opt), 10.4.15 (dbg), 10.4.15 (opt), 10.5.6 (dbg), 10.5.6 (opt) Bug confirmed not present in: MariaDB: 10.1.47 (dbg), 10.1.47 (opt) MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.47 (dbg), 5.6.47 (opt), 5.7.29 (dbg), 5.7.29 (opt), 8.0.19 (dbg), 8.0.19 (opt)

            Here is a slightly simpler test case. It could probably be simplified even further:

            --source include/have_innodb.inc
            SET GLOBAL innodb_prefix_index_cluster_optimization=1;
            CREATE TABLE t(c POINT UNIQUE) ENGINE=InnoDB;
            INSERT t SET c=POINT(1,1);
            SELECT * FROM t WHERE c > (SELECT MAX(c) FROM t);
            DROP TABLE t;
            

            Internally, geometry data types derive from Field_blob, and in fact, the index will be treated as a prefix index: c(25). But, I was unable to come up with a test case that would have used a prefix index on a BLOB column.

            The SIGFPE occurs due to a division by zero in the following statement:

            		ulint max_chars = field->prefix_len / templ->mbmaxlen;
            

            I think that multiplication should be preferred to division whenever possible, also for performance reasons.
            Because the underlying encoding is binary, both mbminlen and mbmaxlen are 0. We could treat both as 1, pretending that each byte in the binary string is a character.

            marko Marko Mäkelä added a comment - Here is a slightly simpler test case. It could probably be simplified even further: --source include/have_innodb.inc SET GLOBAL innodb_prefix_index_cluster_optimization=1; CREATE TABLE t(c POINT UNIQUE ) ENGINE=InnoDB; INSERT t SET c=POINT(1,1); SELECT * FROM t WHERE c > ( SELECT MAX (c) FROM t); DROP TABLE t; Internally, geometry data types derive from Field_blob , and in fact, the index will be treated as a prefix index: c(25) . But, I was unable to come up with a test case that would have used a prefix index on a BLOB column. The SIGFPE occurs due to a division by zero in the following statement: ulint max_chars = field->prefix_len / templ->mbmaxlen; I think that multiplication should be preferred to division whenever possible, also for performance reasons. Because the underlying encoding is binary, both mbminlen and mbmaxlen are 0. We could treat both as 1, pretending that each byte in the binary string is a character.

            Or perhaps disable - or bypass/ignore? - MAX() and similar functions on binary data (rather then arbitrary number)?

            Roel Roel Van de Paar added a comment - Or perhaps disable - or bypass/ignore? - MAX() and similar functions on binary data (rather then arbitrary number)?

            Roel, can you please check the tests mentioned in my initial fix? That fix is missing one more check:

            diff --git a/storage/innobase/row/row0sel.cc b/storage/innobase/row/row0sel.cc
            index 897b0991933..369e3b0f25b 100644
            --- a/storage/innobase/row/row0sel.cc
            +++ b/storage/innobase/row/row0sel.cc
            @@ -4174,6 +4174,10 @@ bool row_search_with_covering_prefix(
             	const dict_index_t*	index = prebuilt->index;
             	ut_ad(!dict_index_is_clust(index));
             
            +	if (dict_index_is_spatial(index)) {
            +		return false;
            +	}
            +
             	if (!srv_prefix_index_cluster_optimization) {
             		return false;
             	}
            

            which I found out by running

            ./mtr --parallel=auto --big-test --force --mysqld=--loose-innodb-prefix-index-cluster-optimization
            

            I think that it may have been a mistake to introduce a configuration parameter that is disabled by default, because it means that this feature would never be tested.

            marko Marko Mäkelä added a comment - Roel , can you please check the tests mentioned in my initial fix ? That fix is missing one more check: diff --git a/storage/innobase/row/row0sel.cc b/storage/innobase/row/row0sel.cc index 897b0991933..369e3b0f25b 100644 --- a/storage/innobase/row/row0sel.cc +++ b/storage/innobase/row/row0sel.cc @@ -4174,6 +4174,10 @@ bool row_search_with_covering_prefix( const dict_index_t* index = prebuilt->index; ut_ad(!dict_index_is_clust(index)); + if (dict_index_is_spatial(index)) { + return false; + } + if (!srv_prefix_index_cluster_optimization) { return false; } which I found out by running ./mtr --parallel=auto --big-test --force --mysqld=--loose-innodb-prefix-index-cluster-optimization I think that it may have been a mistake to introduce a configuration parameter that is disabled by default, because it means that this feature would never be tested.

            Patch (attached, supplied by Marko) applied to 10.5 with `patch -p1<10.5.patch` for test branch.

            Roel Roel Van de Paar added a comment - Patch (attached, supplied by Marko) applied to 10.5 with `patch -p1<10.5.patch` for test branch.
            Roel Roel Van de Paar added a comment - - edited

            The three testcases from this bug seem to pass against the patched build and while using --loose-innodb-prefix-index-cluster-optimization or SET GLOBAL innodb_prefix_index_cluster_optimization=1;

            1.

            10.5.6 fe5dbfe723427a3606c41409626dc853f997e679 (Debug)

            10.5.6>INSERT INTO t SELECT * FROM t WHERE c > (SELECT MAX(c) FROM t);
            Query OK, 0 rows affected (0.004 sec)
            Records: 0  Duplicates: 0  Warnings: 0
            

            2.

            10.5.6 fe5dbfe723427a3606c41409626dc853f997e679 (Debug)

            10.5.6>SELECT ST_ASTEXT(p) FROM t1 WHERE p = ST_POINTFROMTEXT('POINT(1 1)');
            +--------------+
            | ST_ASTEXT(p) |
            +--------------+
            | POINT(1 1)   |
            +--------------+
            1 row in set (0.001 sec)
            

            3.

            10.5.6 fe5dbfe723427a3606c41409626dc853f997e679 (Debug)

            10.5.6>DROP TABLE t;
            Query OK, 0 rows affected (0.007 sec)
            

            Roel Roel Van de Paar added a comment - - edited The three testcases from this bug seem to pass against the patched build and while using --loose-innodb-prefix-index-cluster-optimization or SET GLOBAL innodb_prefix_index_cluster_optimization=1; 1. 10.5.6 fe5dbfe723427a3606c41409626dc853f997e679 (Debug) 10.5.6>INSERT INTO t SELECT * FROM t WHERE c > (SELECT MAX(c) FROM t); Query OK, 0 rows affected (0.004 sec) Records: 0 Duplicates: 0 Warnings: 0 2. 10.5.6 fe5dbfe723427a3606c41409626dc853f997e679 (Debug) 10.5.6>SELECT ST_ASTEXT(p) FROM t1 WHERE p = ST_POINTFROMTEXT('POINT(1 1)'); +--------------+ | ST_ASTEXT(p) | +--------------+ | POINT(1 1) | +--------------+ 1 row in set (0.001 sec) 3. 10.5.6 fe5dbfe723427a3606c41409626dc853f997e679 (Debug) 10.5.6>DROP TABLE t; Query OK, 0 rows affected (0.007 sec)
            Roel Roel Van de Paar added a comment - - edited

            Testcase from MDEV-20464 seems to pass against the patched build, idem mysqld option as above.

            10.5.6 fe5dbfe723427a3606c41409626dc853f997e679 (Debug)

            10.5.6>SELECT f1, MAX(f3), COUNT(f4) FROM t1 GROUP BY f1;
            +------+---------+-----------+
            | f1   | MAX(f3) | COUNT(f4) |
            +------+---------+-----------+
            | NULL |    NULL |         0 |
            |    0 |       0 |         1 |
            +------+---------+-----------+
            2 rows in set (0.000 sec)
            

            Roel Roel Van de Paar added a comment - - edited Testcase from MDEV-20464 seems to pass against the patched build, idem mysqld option as above. 10.5.6 fe5dbfe723427a3606c41409626dc853f997e679 (Debug) 10.5.6>SELECT f1, MAX(f3), COUNT(f4) FROM t1 GROUP BY f1; +------+---------+-----------+ | f1 | MAX(f3) | COUNT(f4) | +------+---------+-----------+ | NULL | NULL | 0 | | 0 | 0 | 1 | +------+---------+-----------+ 2 rows in set (0.000 sec)
            Roel Roel Van de Paar added a comment - - edited

            Actual result correctness not checked (for any testcase)

            Roel Roel Van de Paar added a comment - - edited Actual result correctness not checked (for any testcase)

            MTR results for:

            ./mtr --parallel=auto --big-test --force --mysqld=--loose-innodb-prefix-index-cluster-optimization
            

            10.5.6 fe5dbfe723427a3606c41409626dc853f997e679 (Debug)

            The servers were restarted 1815 times
            ...
            Check of testcase failed for: main.fast_prefix_index_fetch_innodb
             
            Completed: Failed 5/6234 tests, 99.92% were successful.
             
            Failing test(s): binlog.flashback-largebinlog binlog.binlog_commit_wait sys_vars.innodb_prefix_index_cluster_optimization_basic innodb.monitor main.innodb_ext_key
             
            The log files in var/log may give you some hint of what went wrong.
             
            If you want to report this error, please read first the documentation
            at http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html
             
            Errors/warnings were found in logfiles during server shutdown after running the
            following sequence(s) of tests:
                main.ctype_upgrade main.alter_table main.gis-alter_table_online main.foreign_key main.group_min_max_innodb innodb_i_s.innodb_locks main.group_by_innodb main.innodb_ext_key main.flush-innodb innodb_i_s.innodb_sys_indexes innodb_i_s.innodb_trx main.func_group_innodb main.explain_json_innodb main.flush_read_lock_kill innodb_zip.index_large_prefix_8k main.flush-innodb-notembedded main.consistent_snapshot main.flush_block_commit main.ext_key_noPK_6794 main.events_trans innodb_gis.rtree_drop_index innodb_i_s.innodb_sys_fields main.innodb_bug878769 innodb_i_s.innodb_sys_columns
            298 tests were skipped, 239 by the test itself.
             
            mysql-test-run: *** ERROR: there were failing test cases
            

            Roel Roel Van de Paar added a comment - MTR results for: ./mtr --parallel=auto --big-test --force --mysqld=--loose-innodb-prefix-index-cluster-optimization 10.5.6 fe5dbfe723427a3606c41409626dc853f997e679 (Debug) The servers were restarted 1815 times ... Check of testcase failed for: main.fast_prefix_index_fetch_innodb   Completed: Failed 5/6234 tests, 99.92% were successful.   Failing test(s): binlog.flashback-largebinlog binlog.binlog_commit_wait sys_vars.innodb_prefix_index_cluster_optimization_basic innodb.monitor main.innodb_ext_key   The log files in var/log may give you some hint of what went wrong.   If you want to report this error, please read first the documentation at http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html   Errors/warnings were found in logfiles during server shutdown after running the following sequence(s) of tests: main.ctype_upgrade main.alter_table main.gis-alter_table_online main.foreign_key main.group_min_max_innodb innodb_i_s.innodb_locks main.group_by_innodb main.innodb_ext_key main.flush-innodb innodb_i_s.innodb_sys_indexes innodb_i_s.innodb_trx main.func_group_innodb main.explain_json_innodb main.flush_read_lock_kill innodb_zip.index_large_prefix_8k main.flush-innodb-notembedded main.consistent_snapshot main.flush_block_commit main.ext_key_noPK_6794 main.events_trans innodb_gis.rtree_drop_index innodb_i_s.innodb_sys_fields main.innodb_bug878769 innodb_i_s.innodb_sys_columns 298 tests were skipped, 239 by the test itself.   mysql-test-run: *** ERROR: there were failing test cases

            MTR Full log updated, some evidence of crash(es). MDEV-23600_stdout.log

            Roel Roel Van de Paar added a comment - MTR Full log updated, some evidence of crash(es). MDEV-23600_stdout.log

            MDEV-23600_stdout.log includes the following failure, which seems to be caused by enabling the feature:

            10.5 fe5dbfe723427a3606c41409626dc853f997e679 with patch

            CURRENT_TEST: main.innodb_ext_key
            mysqltest: At line 690: query 'analyze table t1,t2' failed: 2013: Lost connection to MySQL server during query
             
            The result from queries just before the failure was:
            < snip >
            1	SIMPLE	t3	eq_ref	PRIMARY	PRIMARY	4	test.t2.rev_text_id	1	
            set optimizer_switch='extended_keys=on';
            EXPLAIN 
            SELECT *  FROM t1, t2 IGNORE INDEX (PRIMARY), t3 
            WHERE page_id=rev_page AND  rev_text_id=old_id  AND page_namespace=4 AND page_title='Sandbox'
            ORDER BY rev_timestamp ASC LIMIT 10;
            id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
            1	SIMPLE	t1	const	PRIMARY,name_title	name_title	261	const,const	1	
            1	SIMPLE	t2	ref	page_timestamp	page_timestamp	4	const	10	Using where
            1	SIMPLE	t3	eq_ref	PRIMARY	PRIMARY	4	test.t2.rev_text_id	1	
            DROP TABLE t1,t2,t3;
            #
            # MDEV-5424 SELECT using ORDER BY DESC and LIMIT produces unexpected
            # results (InnoDB/XtraDB)
            #
            create table t1 (a bigint not null unique auto_increment, b varchar(10), primary key (a), key (b(2))) engine = myisam default character set utf8;
            create table t2 (a bigint not null unique auto_increment, b varchar(10), primary key (a), key (b(2))) engine = innodb default character set utf8;
            insert into t1 (b) values (null), (null), (null);
            insert into t2 (b) values (null), (null), (null);
            analyze table t1,t2;
            …
            #3  <signal handler called>
            #4  my_valid_mbcharlen_utf8mb3 (e=0x14ac2cdac07d <error: Cannot access memory at address 0x14ac2cdac07d>, s=0x14ab2d2c3fff "\357"<error: Cannot access memory at address 0x14ab2d2c4000>) at /test/10.5_dbg/strings/ctype-utf8.c:103
            #5  my_charlen_utf8mb3 (cs=0x55d1a236e820 <my_charset_utf8mb3_general_ci>, s=0x14ab2d2c3fff "\357"<error: Cannot access memory at address 0x14ab2d2c4000>, e=0x14ac2cdac07d <error: Cannot access memory at address 0x14ac2cdac07d>) at /test/10.5_dbg/strings/ctype-utf8.c:5207
            #6  0x000055d1a1650993 in my_ismbchar (end=0x14ac2cdac07d <error: Cannot access memory at address 0x14ac2cdac07d>, str=0x14ab2d2c3fff "\357"<error: Cannot access memory at address 0x14ab2d2c4000>, cs=0x55d1a236e820 <my_charset_utf8mb3_general_ci>) at /test/10.5_dbg/include/m_ctype.h:1554
            #7  my_numchars_mb (cs=0x55d1a236e820 <my_charset_utf8mb3_general_ci>, pos=0x14ab2d2c3fff "\357"<error: Cannot access memory at address 0x14ab2d2c4000>, end=0x14ac2cdac07d <error: Cannot access memory at address 0x14ac2cdac07d>) at /test/10.5_dbg/strings/ctype-mb.c:310
            #8  0x000055d1a136f3f9 in charset_info_st::numchars (e=<optimized out>, b=<optimized out>, this=0x55d1a236e820 <my_charset_utf8mb3_general_ci>) at /test/10.5_dbg/include/m_ctype.h:608
            #9  rec_field_len_in_chars (offsets=0x14ab2c82a580, rec=0x14ab2cdac07e "\200", field_no=0, col=<optimized out>) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:4076
            #10 row_search_with_covering_prefix (offsets=0x14ab2c82a580, rec=0x14ab2cdac07e "\200", prebuilt=0x14ab07c12d88) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:4138
            #11 row_search_mvcc (buf=buf@entry=0x14ab04aeac08 "\377\003", mode=PAGE_CUR_G, prebuilt=0x14ab07c12d88, match_mode=<optimized out>, direction=direction@entry=0) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:5220
            #12 0x000055d1a11c3f06 in ha_innobase::index_read (this=this@entry=0x14ab07c11dd0, buf=buf@entry=0x14ab04aeac08 "\377\003", key_ptr=key_ptr@entry=0x0, key_len=key_len@entry=0, find_flag=find_flag@entry=HA_READ_AFTER_KEY) at /test/10.5_dbg/storage/innobase/handler/ha_innodb.cc:8763
            …
            

            I can repeat that failure even on 10.2 with my current work-in-progress patch:

            10.2

            #2  <signal handler called>
            #3  my_charlen_utf8 (cs=0x559195f09dc0 <my_charset_utf8_general_ci>, s=0x7fc8b6f5d000 <error: Cannot access memory at address 0x7fc8b6f5d000>, e=0x7fc9b681807d <error: Cannot access memory at address 0x7fc9b681807d>) at /mariadb/10.2o/strings/ctype-utf8.c:5394
            #4  0x0000559195777ad6 in my_ismbchar (cs=0x559195f09dc0 <my_charset_utf8_general_ci>, str=0x7fc8b6f5d000 <error: Cannot access memory at address 0x7fc8b6f5d000>, end=0x7fc9b681807d <error: Cannot access memory at address 0x7fc9b681807d>) at /mariadb/10.2o/include/m_ctype.h:1050
            #5  my_numchars_mb (cs=0x559195f09dc0 <my_charset_utf8_general_ci>, pos=0x7fc8b6f5d000 <error: Cannot access memory at address 0x7fc8b6f5d000>, end=0x7fc9b681807d <error: Cannot access memory at address 0x7fc9b681807d>) at /mariadb/10.2o/strings/ctype-mb.c:310
            #6  0x000055919541c79b in rec_field_len_in_chars (col=<optimized out>, field_no=0, rec=0x7fc8b681807e "\200", offsets=0x7fc8b5e73aa0) at /mariadb/10.2o/storage/innobase/row/row0sel.cc:4159
            

            Maybe the failure is nondeterministic, or I overlooked it when I ran all 10.2 tests with the setting enabled.

            marko Marko Mäkelä added a comment - MDEV-23600_stdout.log includes the following failure, which seems to be caused by enabling the feature: 10.5 fe5dbfe723427a3606c41409626dc853f997e679 with patch CURRENT_TEST: main.innodb_ext_key mysqltest: At line 690: query 'analyze table t1,t2' failed: 2013: Lost connection to MySQL server during query   The result from queries just before the failure was: < snip > 1 SIMPLE t3 eq_ref PRIMARY PRIMARY 4 test.t2.rev_text_id 1 set optimizer_switch='extended_keys=on'; EXPLAIN SELECT * FROM t1, t2 IGNORE INDEX (PRIMARY), t3 WHERE page_id=rev_page AND rev_text_id=old_id AND page_namespace=4 AND page_title='Sandbox' ORDER BY rev_timestamp ASC LIMIT 10; id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE t1 const PRIMARY,name_title name_title 261 const,const 1 1 SIMPLE t2 ref page_timestamp page_timestamp 4 const 10 Using where 1 SIMPLE t3 eq_ref PRIMARY PRIMARY 4 test.t2.rev_text_id 1 DROP TABLE t1,t2,t3; # # MDEV-5424 SELECT using ORDER BY DESC and LIMIT produces unexpected # results (InnoDB/XtraDB) # create table t1 (a bigint not null unique auto_increment, b varchar(10), primary key (a), key (b(2))) engine = myisam default character set utf8; create table t2 (a bigint not null unique auto_increment, b varchar(10), primary key (a), key (b(2))) engine = innodb default character set utf8; insert into t1 (b) values (null), (null), (null); insert into t2 (b) values (null), (null), (null); analyze table t1,t2; … #3 <signal handler called> #4 my_valid_mbcharlen_utf8mb3 (e=0x14ac2cdac07d <error: Cannot access memory at address 0x14ac2cdac07d>, s=0x14ab2d2c3fff "\357"<error: Cannot access memory at address 0x14ab2d2c4000>) at /test/10.5_dbg/strings/ctype-utf8.c:103 #5 my_charlen_utf8mb3 (cs=0x55d1a236e820 <my_charset_utf8mb3_general_ci>, s=0x14ab2d2c3fff "\357"<error: Cannot access memory at address 0x14ab2d2c4000>, e=0x14ac2cdac07d <error: Cannot access memory at address 0x14ac2cdac07d>) at /test/10.5_dbg/strings/ctype-utf8.c:5207 #6 0x000055d1a1650993 in my_ismbchar (end=0x14ac2cdac07d <error: Cannot access memory at address 0x14ac2cdac07d>, str=0x14ab2d2c3fff "\357"<error: Cannot access memory at address 0x14ab2d2c4000>, cs=0x55d1a236e820 <my_charset_utf8mb3_general_ci>) at /test/10.5_dbg/include/m_ctype.h:1554 #7 my_numchars_mb (cs=0x55d1a236e820 <my_charset_utf8mb3_general_ci>, pos=0x14ab2d2c3fff "\357"<error: Cannot access memory at address 0x14ab2d2c4000>, end=0x14ac2cdac07d <error: Cannot access memory at address 0x14ac2cdac07d>) at /test/10.5_dbg/strings/ctype-mb.c:310 #8 0x000055d1a136f3f9 in charset_info_st::numchars (e=<optimized out>, b=<optimized out>, this=0x55d1a236e820 <my_charset_utf8mb3_general_ci>) at /test/10.5_dbg/include/m_ctype.h:608 #9 rec_field_len_in_chars (offsets=0x14ab2c82a580, rec=0x14ab2cdac07e "\200", field_no=0, col=<optimized out>) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:4076 #10 row_search_with_covering_prefix (offsets=0x14ab2c82a580, rec=0x14ab2cdac07e "\200", prebuilt=0x14ab07c12d88) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:4138 #11 row_search_mvcc (buf=buf@entry=0x14ab04aeac08 "\377\003", mode=PAGE_CUR_G, prebuilt=0x14ab07c12d88, match_mode=<optimized out>, direction=direction@entry=0) at /test/10.5_dbg/storage/innobase/row/row0sel.cc:5220 #12 0x000055d1a11c3f06 in ha_innobase::index_read (this=this@entry=0x14ab07c11dd0, buf=buf@entry=0x14ab04aeac08 "\377\003", key_ptr=key_ptr@entry=0x0, key_len=key_len@entry=0, find_flag=find_flag@entry=HA_READ_AFTER_KEY) at /test/10.5_dbg/storage/innobase/handler/ha_innodb.cc:8763 … I can repeat that failure even on 10.2 with my current work-in-progress patch: 10.2 #2 <signal handler called> #3 my_charlen_utf8 (cs=0x559195f09dc0 <my_charset_utf8_general_ci>, s=0x7fc8b6f5d000 <error: Cannot access memory at address 0x7fc8b6f5d000>, e=0x7fc9b681807d <error: Cannot access memory at address 0x7fc9b681807d>) at /mariadb/10.2o/strings/ctype-utf8.c:5394 #4 0x0000559195777ad6 in my_ismbchar (cs=0x559195f09dc0 <my_charset_utf8_general_ci>, str=0x7fc8b6f5d000 <error: Cannot access memory at address 0x7fc8b6f5d000>, end=0x7fc9b681807d <error: Cannot access memory at address 0x7fc9b681807d>) at /mariadb/10.2o/include/m_ctype.h:1050 #5 my_numchars_mb (cs=0x559195f09dc0 <my_charset_utf8_general_ci>, pos=0x7fc8b6f5d000 <error: Cannot access memory at address 0x7fc8b6f5d000>, end=0x7fc9b681807d <error: Cannot access memory at address 0x7fc9b681807d>) at /mariadb/10.2o/strings/ctype-mb.c:310 #6 0x000055919541c79b in rec_field_len_in_chars (col=<optimized out>, field_no=0, rec=0x7fc8b681807e "\200", offsets=0x7fc8b5e73aa0) at /mariadb/10.2o/storage/innobase/row/row0sel.cc:4159 Maybe the failure is nondeterministic, or I overlooked it when I ran all 10.2 tests with the setting enabled.

            The problem with the test main.innodb_ext_key appears to be that we were trying to access a column that is NULL.

            marko Marko Mäkelä added a comment - The problem with the test main.innodb_ext_key appears to be that we were trying to access a column that is NULL.

            I pushed a fix to 10.1 for MDEV-12486, MDEV-20422, MDEV-23600 and merged to 10.2 (also fixing MDEV-20464 in 10.2). Starting with 10.2, we got additional crashes in

            ./mtr --mysqld=--loose-innodb-prefix-index-cluster-optimization --suite=innodb_gis
            

            because the optimization was wrongly being attempted on spatial indexes.

            marko Marko Mäkelä added a comment - I pushed a fix to 10.1 for MDEV-12486 , MDEV-20422 , MDEV-23600 and merged to 10.2 (also fixing MDEV-20464 in 10.2). Starting with 10.2, we got additional crashes in ./mtr --mysqld=--loose-innodb-prefix-index-cluster-optimization --suite=innodb_gis because the optimization was wrongly being attempted on spatial indexes.

            People

              marko Marko Mäkelä
              Roel Roel Van de Paar
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.