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

Assertion `i < get_width()' failed in Histogram::get_value

    XMLWordPrintable

    Details

      Description

      I am setting it to Minor due to the unrealistic value of histogram_size. However, I can't tell for sure whether the failure is specific to the meaningless histogram_size or just the combination of histogram_size and data volume/values. I expect the development analysis will clarify it.

      CREATE TABLE t1 (a INT);
      INSERT INTO t1 VALUES (1),(2),(3),(4),(5),(6),(7),(8);
      INSERT INTO t1 SELECT * FROM t1;
      ALTER TABLE t1 ADD SYSTEM VERSIONING;
      INSERT INTO t1 VALUES (1),(2),(3),(4);
      SET HISTOGRAM_SIZE= 5;
      ANALYZE TABLE t1 PERSISTENT FOR ALL;
      SELECT * from t1 WHERE row_start IN (SELECT row_end FROM t1);
       
      # Cleanup
      DROP TABLE t1;
      

      10.4 debug 5d471453

      mysqld: /data/src/10.4/sql/sql_statistics.h:177: uint Histogram::get_value(uint): Assertion `i < get_width()' failed.
      200712 15:19:19 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f954b92bf12 in __GI___assert_fail (assertion=0x563fefef8385 "i < get_width()", file=0x563fefef8398 "/data/src/10.4/sql/sql_statistics.h", line=177, function=0x563fefef8d00 <Histogram::get_value(unsigned int)::__PRETTY_FUNCTION__> "uint Histogram::get_value(uint)") at assert.c:101
      #8  0x0000563fef2af103 in Histogram::get_value (this=0x7f94e4057c90, i=2) at /data/src/10.4/sql/sql_statistics.h:177
      #9  0x0000563fef2af238 in Histogram::find_bucket (this=0x7f94e4057c90, pos=1, first=true) at /data/src/10.4/sql/sql_statistics.h:201
      #10 0x0000563fef2ae3e3 in Histogram::point_selectivity (this=0x7f94e4057c90, pos=1, avg_sel=0.5) at /data/src/10.4/sql/sql_statistics.cc:3874
      #11 0x0000563fef2ae181 in get_column_range_cardinality (field=0x7f94e4077430, min_endp=0x7f95481783c0, max_endp=0x7f95481783e0, range_flag=48) at /data/src/10.4/sql/sql_statistics.cc:3783
      #12 0x0000563fef6b9ead in records_in_column_ranges (param=0x7f9548178c00, idx=0, tree=0x7f94e405c570) at /data/src/10.4/sql/opt_range.cc:3234
      #13 0x0000563fef6baaf7 in calculate_cond_selectivity_for_table (thd=0x7f94e4000af0, table=0x7f94e413e6f0, cond=0x7f94e40162c0) at /data/src/10.4/sql/opt_range.cc:3498
      #14 0x0000563fef237c7f in make_join_statistics (join=0x7f94e4015eb8, tables_list=..., keyuse_array=0x7f94e40161a8) at /data/src/10.4/sql/sql_select.cc:5476
      #15 0x0000563fef22c1f2 in JOIN::optimize_inner (this=0x7f94e4015eb8) at /data/src/10.4/sql/sql_select.cc:2263
      #16 0x0000563fef229b32 in JOIN::optimize (this=0x7f94e4015eb8) at /data/src/10.4/sql/sql_select.cc:1610
      #17 0x0000563fef234fda in mysql_select (thd=0x7f94e4000af0, tables=0x7f94e4013628, wild_num=1, fields=..., conds=0x7f94e40152c8, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f94e4015e90, unit=0x7f94e4004a18, select_lex=0x7f94e4013068) at /data/src/10.4/sql/sql_select.cc:4673
      #18 0x0000563fef224b46 in handle_select (thd=0x7f94e4000af0, lex=0x7f94e4004958, result=0x7f94e4015e90, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:422
      #19 0x0000563fef1eb628 in execute_sqlcom_select (thd=0x7f94e4000af0, all_tables=0x7f94e4013628) at /data/src/10.4/sql/sql_parse.cc:6358
      #20 0x0000563fef1e1c5f in mysql_execute_command (thd=0x7f94e4000af0) at /data/src/10.4/sql/sql_parse.cc:3890
      #21 0x0000563fef1ef5d5 in mysql_parse (thd=0x7f94e4000af0, rawbuf=0x7f94e4012f88 "SELECT * from t1 WHERE row_start IN (SELECT row_end FROM t1)", length=60, parser_state=0x7f954817a5c0, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7899
      #22 0x0000563fef1dbb0a in dispatch_command (command=COM_QUERY, thd=0x7f94e4000af0, packet=0x7f94e414e0d1 "SELECT * from t1 WHERE row_start IN (SELECT row_end FROM t1)", packet_length=60, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1834
      #23 0x0000563fef1da2ac in do_command (thd=0x7f94e4000af0) at /data/src/10.4/sql/sql_parse.cc:1352
      #24 0x0000563fef363188 in do_handle_one_connection (connect=0x563ff2e99a80) at /data/src/10.4/sql/sql_connect.cc:1412
      #25 0x0000563fef362ed7 in handle_one_connection (arg=0x563ff2e99a80) at /data/src/10.4/sql/sql_connect.cc:1316
      #26 0x00007f954d8b44a4 in start_thread (arg=0x7f954817b700) at pthread_create.c:456
      #27 0x00007f954b9e8d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
      

      Reproducible on 10.4-10.5, with at least MyISAM and InnoDB.
      Couldn't reproduce on 10.3, even after adding USE_STAT_TABLES=PREFERABLY, OPTIMIZER_USE_CONDITION_SELECTIVITY=4, HISTOGRAM_TYPE=DOUBLE_PREC_HB. Maybe I missed some important options.

      Couldn't reproduce without versioning, with explicit timestamp columns.

      No obvious problem on a non-debug build.

        Attachments

          Activity

            People

            Assignee:
            psergei Sergei Petrunia
            Reporter:
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:

                Git Integration