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

Assertion `(((nr) % (1LL << 24)) % (int) log_10_int[6 - dec]) == 0' failed in my_time_packed_to_binary

    XMLWordPrintable

    Details

      Description

      The test case is admittedly stupid, I'm only keeping it Major because it appears to be a recent regression.

      CREATE TABLE t1 (a CHAR(8));
      INSERT INTO t1 VALUES (''),('');
      SELECT MAX(TIMEDIFF(171727883291171, '2020-12-12')) AS x FROM t1;
      SELECT WEEKOFYEAR(a) AS f, MAX(TIMEDIFF(171727883291171, '2020-12-12')) AS x FROM t1 GROUP BY f;
       
      # Cleanup
      DROP TABLE t1;
      

      10.4 1cda462f

      mysqld: /data/src/10.4/sql/compat56.cc:127: void my_time_packed_to_binary(longlong, uchar*, uint): Assertion `(((nr) % (1LL << 24)) % (int) log_10_int[6 - dec]) == 0' failed.
      200905  2:25:32 [ERROR] mysqld got signal 6 ;
       
      #6  0x00007f729d738e67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x5599157abc50 "(((nr) % (1LL << 24)) % (int) log_10_int[6 - dec]) == 0", file=file@entry=0x5599157abb90 "/data/src/10.4/sql/compat56.cc", line=line@entry=127, function=function@entry=0x5599157abea0 <my_time_packed_to_binary(long long, unsigned char*, unsigned int)::__PRETTY_FUNCTION__> "void my_time_packed_to_binary(longlong, uchar*, uint)") at assert.c:92
      #7  0x00007f729d738f12 in __GI___assert_fail (assertion=0x5599157abc50 "(((nr) % (1LL << 24)) % (int) log_10_int[6 - dec]) == 0", file=0x5599157abb90 "/data/src/10.4/sql/compat56.cc", line=127, function=0x5599157abea0 <my_time_packed_to_binary(long long, unsigned char*, unsigned int)::__PRETTY_FUNCTION__> "void my_time_packed_to_binary(longlong, uchar*, uint)") at assert.c:101
      #8  0x0000559914c40faf in my_time_packed_to_binary (nr=57629452747327, ptr=0x7f727c0159ae "\245\245\245", dec=0) at /data/src/10.4/sql/compat56.cc:126
      #9  0x0000559914b3dac0 in Time::to_native (this=0x7f72980e2010, to=0x7f727c015998, decimals=0) at /data/src/10.4/sql/sql_type.cc:642
      #10 0x0000559914b605b8 in Item_timefunc::val_native (this=0x7f727c013bd8, thd=0x7f727c000af0, to=0x7f727c015998) at /data/src/10.4/sql/item_timefunc.h:603
      #11 0x0000559914d84eb6 in Arg_comparator::min_max_update_field_native (this=0x7f727c0158d0, thd=0x7f727c000af0, field=0x7f727c0645b0, item=0x7f727c013bd8, cmp_sign=-1) at /data/src/10.4/sql/item_sum.cc:3113
      #12 0x0000559914d85172 in Item_sum_min_max::min_max_update_native_field (this=0x7f727c013c98) at /data/src/10.4/sql/item_sum.cc:3136
      #13 0x0000559914d84d71 in Item_sum_min_max::update_field (this=0x7f727c013c98) at /data/src/10.4/sql/item_sum.cc:3079
      #14 0x00005599149b35e6 in update_tmptable_sum_func (func_ptr=0x7f727c015a48, tmp_table=0x7f727c064e98) at /data/src/10.4/sql/sql_select.cc:25435
      #15 0x00005599149aa485 in end_update (join=0x7f727c014fa0, join_tab=0x7f727c016a08, end_of_records=false) at /data/src/10.4/sql/sql_select.cc:21919
      #16 0x00005599149bd1ae in AGGR_OP::put_record (this=0x7f727c0173f0, end_of_records=false) at /data/src/10.4/sql/sql_select.cc:28675
      #17 0x00005599149c31af in AGGR_OP::put_record (this=0x7f727c0173f0) at /data/src/10.4/sql/sql_select.h:1048
      #18 0x00005599149a5eb6 in sub_select_postjoin_aggr (join=0x7f727c014fa0, join_tab=0x7f727c016a08, end_of_records=false) at /data/src/10.4/sql/sql_select.cc:20128
      #19 0x00005599149a6b2c in evaluate_join_record (join=0x7f727c014fa0, join_tab=0x7f727c016660, error=0) at /data/src/10.4/sql/sql_select.cc:20628
      #20 0x00005599149a65c7 in sub_select (join=0x7f727c014fa0, join_tab=0x7f727c016660, end_of_records=false) at /data/src/10.4/sql/sql_select.cc:20447
      #21 0x00005599149a58fb in do_select (join=0x7f727c014fa0, procedure=0x0) at /data/src/10.4/sql/sql_select.cc:19946
      #22 0x000055991497a749 in JOIN::exec_inner (this=0x7f727c014fa0) at /data/src/10.4/sql/sql_select.cc:4478
      #23 0x0000559914979886 in JOIN::exec (this=0x7f727c014fa0) at /data/src/10.4/sql/sql_select.cc:4260
      #24 0x000055991497afe9 in mysql_select (thd=0x7f727c000af0, tables=0x7f727c013e48, wild_num=0, fields=..., conds=0x0, og_num=1, order=0x0, group=0x7f727c014638, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f727c014f78, unit=0x7f727c004a18, select_lex=0x7f727c0132b8) at /data/src/10.4/sql/sql_select.cc:4695
      #25 0x000055991496a9a6 in handle_select (thd=0x7f727c000af0, lex=0x7f727c004958, result=0x7f727c014f78, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:422
      #26 0x0000559914931120 in execute_sqlcom_select (thd=0x7f727c000af0, all_tables=0x7f727c013e48) at /data/src/10.4/sql/sql_parse.cc:6355
      #27 0x0000559914927757 in mysql_execute_command (thd=0x7f727c000af0) at /data/src/10.4/sql/sql_parse.cc:3889
      #28 0x00005599149350cd in mysql_parse (thd=0x7f727c000af0, rawbuf=0x7f727c013198 "SELECT WEEKOFYEAR(a) AS f, MAX(TIMEDIFF(171727883291171, '2020-12-12')) AS x FROM t1 GROUP BY f", length=95, parser_state=0x7f72980e3570, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7896
      #29 0x0000559914921601 in dispatch_command (command=COM_QUERY, thd=0x7f727c000af0, packet=0x7f727c1364f1 "", packet_length=95, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1835
      #30 0x000055991491fda3 in do_command (thd=0x7f727c000af0) at /data/src/10.4/sql/sql_parse.cc:1353
      #31 0x0000559914aa9e3c in do_handle_one_connection (connect=0x559918680ce0) at /data/src/10.4/sql/sql_connect.cc:1412
      #32 0x0000559914aa9b8b in handle_one_connection (arg=0x559918680ce0) at /data/src/10.4/sql/sql_connect.cc:1316
      #33 0x00005599154af2b9 in pfs_spawn_thread (arg=0x55991869c900) at /data/src/10.4/storage/perfschema/pfs.cc:1869
      #34 0x00007f729f6c14a4 in start_thread (arg=0x7f72980e4700) at pthread_create.c:456
      #35 0x00007f729d7f5d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
      

      Reproducible on 10.4+.
      Not reproducible on 10.3.

      The failure started happening on 10.4 branch after this commit:

      commit ae33ebe5b32a82629a40e51c8d6c6611842fbd03
      Author: Alexander Barkov
      Date:   Fri Aug 21 19:41:51 2020 +0400
       
          MDEV-23525 Wrong result of MIN(time_expr) and MAX(time_expr) with GROUP BY
      

      Non-debug build doesn't crash, but the result on it (before and after the patch above) is questionable:

      SELECT MAX(TIMEDIFF(171727883291171, '2020-12-12')) AS x FROM t1;
      x
      838:39:39
      Warnings:
      Warning	1292	Truncated incorrect time value: '171727883291171'
      Warning	1292	Truncated incorrect time value: '2020-12-12'
      

      I suppose with such a meaningless query there is no right answer, and it's a judgement call. MySQL 8.0 returns NULL, which seems logical, since both arguments are incorrect.

        Attachments

          Activity

            People

            Assignee:
            sanja Oleksandr Byelkin
            Reporter:
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:

                Git Integration