[MDEV-23600] SIGFPE in row_search_with_covering_prefix - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
Fix Version/s: 10.1.48, 10.2.35, 10.3.26, 10.4.16, 10.5.7
Component/s: GIS, Storage Engine - InnoDB, Storage Engine - XtraDB
Labels:
- not-10.1

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

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

10.5.patch
3 kB
2020-08-27 09:34
MDEV-23600_stdout.log
668 kB
2020-08-28 07:27

Issue Links

duplicates

MDEV-20464 Signal 8 in row_search_with_covering_prefix with prefix_index_cluster_optimization

Closed

is caused by

MDEV-12255 innodb_prefix_index_cluster_optimization hits debug build assert on UTF-8 columns

Closed

relates to

MDEV-12486 Incorrect results with prefix_index_cluster_optimization enabled

Closed

MDEV-20422 InnoDB: Failing assertion: field->prefix_len > 0 with innodb_prefix_index_cluster_optimization=ON

Closed

MDEV-25440 Assertion `cmp_rec_rec(rec, old_rec, offsets, old_offsets, m_index) > 0' failed in PageBulk::insert

Closed

Activity

Ascending order - Click to sort in descending order

View 8 older comments

Roel Van de Paar added a comment - 2020-08-28 07:24

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 Van de Paar added a comment - 2020-08-28 07:24 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 Van de Paar added a comment - 2020-08-28 07:28

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

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

Marko Mäkelä added a comment - 2020-09-01 09:57

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 Mäkelä added a comment - 2020-09-01 09:57 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 Mäkelä added a comment - 2020-09-01 10:16

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

Marko Mäkelä added a comment - 2020-09-01 10:16 The problem with the test main.innodb_ext_key appears to be that we were trying to access a column that is NULL.

Marko Mäkelä added a comment - 2020-09-01 13:26

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 Mäkelä added a comment - 2020-09-01 13:26 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.

MariaDB Server

SIGFPE in row_search_with_covering_prefix

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration