[MDEV-11736] InnoDB: Failing assertion: n < rec_offs_n_fields(offsets) Created: 2017-01-06  Updated: 2017-01-17  Resolved: 2017-01-17

Status: Closed
Project: MariaDB Server
Component/s: Virtual Columns
Affects Version/s: 10.2
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by MDEV-11541 Wrong result (extra rows) with an ind... Closed
Relates
relates to MDEV-5800 indexes on virtual (not materialized)... Closed

 Description   

10.2 348ccb6f038

 
2017-01-07 00:44:42 0x7fc916212300  InnoDB: Assertion failure in file /data/src/10.2/storage/innobase/include/rem0rec.ic line 1175
 
InnoDB: Failing assertion: n < rec_offs_n_fields(offsets)


#5  0x00007fc912621448 in __GI_abort () at abort.c:89
 
e/innobase/include/rem0rec.ic", line=1175) at /data/src/10.2/storage/innobase/ut/ut0dbg.cc:59
 
#7  0x00007fc91572470c in rec_offs_nth_extern (offsets=0x7fc91620ee80, n=316) at /data/src/10.2/storage/innobase/include/rem0rec.ic:1175
 
#8  0x00007fc91572c8d9 in row_sel_store_mysql_field_func (mysql_rec=0x7fc8ec428488 "\371\002", prebuilt=0x7fc8ec5a5088, rec=0x7fc8fb2c0099 "\200", index=0x7fc8ec565d88, offsets=0x7fc91620ee80, field_no=316, templ=0x7fc8ec690530) at /data/src/10.2/storage/innobase/row/row0sel.cc:3075
 
#9  0x00007fc91572d1f6 in row_sel_store_mysql_rec (mysql_rec=0x7fc8ec428488 "\371\002", prebuilt=0x7fc8ec5a5088, rec=0x7fc8fb2c0099 "\200", vrow=0x0, rec_clust=1, index=0x7fc8ec565d88, offsets=0x7fc91620ee80) at /data/src/10.2/storage/innobase/row/row0sel.cc:3307
 
#10 0x00007fc9157323b4 in row_search_mvcc (buf=0x7fc8ec428488 "\371\002", mode=PAGE_CUR_G, prebuilt=0x7fc8ec5a5088, match_mode=0, direction=1) at /data/src/10.2/storage/innobase/row/row0sel.cc:5540
 
#11 0x00007fc9155ad6dd in ha_innobase::general_fetch (this=0x7fc8ec4b7888, buf=0x7fc8ec428488 "\371\002", direction=1, match_mode=0) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:10648
 
#12 0x00007fc9155ad95c in ha_innobase::index_next (this=0x7fc8ec4b7888, buf=0x7fc8ec428488 "\371\002") at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:10715
 
#13 0x00007fc91536668b in handler::ha_index_next (this=0x7fc8ec4b7888, buf=0x7fc8ec428488 "\371\002") at /data/src/10.2/sql/handler.cc:2677
 
#14 0x00007fc91536cbaa in handler::read_range_next (this=0x7fc8ec4b7888) at /data/src/10.2/sql/handler.cc:5365
 
#15 0x00007fc9152862a0 in handler::multi_range_read_next (this=0x7fc8ec4b7888, range_info=0x7fc91620f978) at /data/src/10.2/sql/multi_range_read.cc:257
 
#16 0x00007fc915286530 in Mrr_simple_index_reader::get_next (this=0x7fc8ec4b7df0, range_info=0x7fc91620f978) at /data/src/10.2/sql/multi_range_read.cc:322
 
#17 0x00007fc91528907a in DsMrr_impl::dsmrr_next (this=0x7fc8ec4b7cb0, range_info=0x7fc91620f978) at /data/src/10.2/sql/multi_range_read.cc:1408
 
#18 0x00007fc9155c197e in ha_innobase::multi_range_read_next (this=0x7fc8ec4b7888, range_info=0x7fc91620f978) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:23488
 
#19 0x00007fc9154bafea in QUICK_RANGE_SELECT::get_next (this=0x7fc8ec501280) at /data/src/10.2/sql/opt_range.cc:11188
 
#20 0x00007fc9154cbe5e in rr_quick (info=0x7fc8ec466990) at /data/src/10.2/sql/records.cc:353
 
#21 0x00007fc9151664e2 in sub_select (join=0x7fc8ec464c70, join_tab=0x7fc8ec4668c8, end_of_records=false) at /data/src/10.2/sql/sql_select.cc:18362
 
#22 0x00007fc9151659ed in do_select (join=0x7fc8ec464c70, procedure=0x0) at /data/src/10.2/sql/sql_select.cc:17887
 
#23 0x00007fc915140a64 in JOIN::exec_inner (this=0x7fc8ec464c70) at /data/src/10.2/sql/sql_select.cc:3388
 
#24 0x00007fc91513ffae in JOIN::exec (this=0x7fc8ec464c70) at /data/src/10.2/sql/sql_select.cc:3199
 
#25 0x00007fc915141105 in mysql_select (thd=0x7fc8ec416070, tables=0x7fc8ec464278, wild_num=1, fields=..., conds=0x7fc8ec464a30, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fc8ec464c50, unit=0x7fc8ec419b48, select_lex=0x7fc8ec41a278) at /data/src/10.2/sql/sql_select.cc:3584
 
#26 0x00007fc9151361bd in handle_select (thd=0x7fc8ec416070, lex=0x7fc8ec419a80, result=0x7fc8ec464c50, setup_tables_done_option=0) at /data/src/10.2/sql/sql_select.cc:373
 
#27 0x00007fc915102969 in execute_sqlcom_select (thd=0x7fc8ec416070, all_tables=0x7fc8ec464278) at /data/src/10.2/sql/sql_parse.cc:6396
 
#28 0x00007fc9150f8458 in mysql_execute_command (thd=0x7fc8ec416070) at /data/src/10.2/sql/sql_parse.cc:3426
 
#29 0x00007fc915106328 in mysql_parse (thd=0x7fc8ec416070, rawbuf=0x7fc8ec464088 "SELECT * FROM t1 WHERE vi < 3", length=29, parser_state=0x7fc916210dd0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7839
 
#30 0x00007fc9150f3eee in dispatch_command (command=COM_QUERY, thd=0x7fc8ec416070, packet=0x7fc8ec458071 "", packet_length=29, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1799
 
#31 0x00007fc9150f28c8 in do_command (thd=0x7fc8ec416070) at /data/src/10.2/sql/sql_parse.cc:1359
 
#32 0x00007fc91523a73e in do_handle_one_connection (connect=0x7fc911c71f70) at /data/src/10.2/sql/sql_connect.cc:1354
 
#33 0x00007fc91523a4cb in handle_one_connection (arg=0x7fc911c71f70) at /data/src/10.2/sql/sql_connect.cc:1260
 
#34 0x00007fc91557932c in pfs_spawn_thread (arg=0x7fc8ff3ed9f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
 
#35 0x00007fc9147260a4 in start_thread (arg=0x7fc916212300) at pthread_create.c:309
 
#36 0x00007fc9126d387d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111


--source include/have_innodb.inc
 
 
 
CREATE TABLE IF NOT EXISTS t1 (`pk` INT AUTO_INCREMENT PRIMARY KEY, i INT, vi INT AS (i*2) VIRTUAL, KEY(vi)) ENGINE=InnoDB;
 
INSERT INTO t1 (i) VALUES (1),(2),(3),(4);
 
 
 
SELECT * FROM t1 WHERE vi < 3;

Note: this assertion failure was also mentioned in a comment to MDEV-11541, but since with the provided test case it happens on 10.2 tree, I'm filing it separately.

 Comments   
Comment by Elena Stepanova [ 2017-01-06 ]

Also reproducible on bb-10.2-monty 4ec3e60ae3.

Comment by Elena Stepanova [ 2017-01-17 ]

Not reproducible anymore on 10.2, maybe Monty has fixed it.

Comment by Elena Stepanova [ 2017-01-17 ]

Now (as of 10.2 fd0479ce592e0b7c) it produces a wrong results instead:

MariaDB [test]> CREATE TABLE IF NOT EXISTS t1 (`pk` INT AUTO_INCREMENT PRIMARY KEY, i INT, vi INT AS (i*2) VIRTUAL, KEY(vi)) ENGINE=InnoDB;
 
Query OK, 0 rows affected (0.45 sec)
 
 
 
MariaDB [test]> INSERT INTO t1 (i) VALUES (1),(2),(3),(4);
 
Query OK, 4 rows affected (0.04 sec)
 
Records: 4  Duplicates: 0  Warnings: 0
 
 
 
MariaDB [test]>  
MariaDB [test]> SELECT * FROM t1 WHERE vi < 3;
 
+----+------+------+
 
| pk | i    | vi   |
 
+----+------+------+
 
|  1 |    1 |    2 |
 
|  2 |    2 |    4 |
 
|  3 |    3 |    6 |
 
|  4 |    4 |    8 |
 
+----+------+------+
 
4 rows in set (0.00 sec)

Comment by Elena Stepanova [ 2017-01-17 ]

The assertion failure was apparently fixed by this commit:

commit c9b3e4535bb4b6d2aa0f7bc1ce71730e6aceca8b
 
Author: Monty <monty@mariadb.org>
 
Date:   Mon Jan 9 18:46:20 2017 +0200
 
 
 
    MDEV-11737 Failing assertion: block->magic_n == MEM_BLOCK_MAGIC_N
 
    
    Issue was that the m_prebuilt array was reused without resetting a counter,
 
    which caused a memory overrun.
 
    
    Adjusted test case to 79 characters

I think it can now be considered a duplicate of MDEV-11541. I'll add the test case there for completeness.

Generated at Thu Feb 08 07:52:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.