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

InnoDB: Failing assertion: n < rec_offs_n_fields(offsets)

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • 10.2(EOL)
    • N/A
    • Virtual Columns
    • None

    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.

      Attachments

        Issue Links

          Activity

            Also reproducible on bb-10.2-monty 4ec3e60ae3.

            elenst Elena Stepanova added a comment - Also reproducible on bb-10.2-monty 4ec3e60ae3.

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

            elenst Elena Stepanova added a comment - Not reproducible anymore on 10.2, maybe Monty has fixed it.

            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)
            

            elenst Elena Stepanova added a comment - 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)
            elenst Elena Stepanova added a comment - - edited

            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.

            elenst Elena Stepanova added a comment - - edited 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.

            People

              Unassigned Unassigned
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              1 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.