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

Assertion `0' in Type_handler_string_result::make_sort_key or unexpected result

    XMLWordPrintable

Details

    • Bug
    • Status: Confirmed (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.5, 10.6, 10.11, 10.4(EOL), 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 11.0(EOL)
    • 10.5, 10.6, 10.11
    • Server
    • None

    Description

      Note: The test case uses an application period, so it's only runnable on 10.4+. However, I'm not sure the problem has anything to do with application periods as such, more likely it's just the combination of hidden indexes, checks and whatever that it brings to the table. Hopefully it will be clearer after analysis, please re-categorize as needed.

      CREATE TABLE t (s DATE, e DATE, PERIOD FOR p(s,e));
      		 
      INSERT INTO t (s,e) VALUES ('1970-01-01','1970-01-02'),('1980-01-01','1980-01-02');
      		 
       
      		 
      SET sql_mode=REPLACE(REPLACE(@@sql_mode,'STRICT_TRANS_TABLES',''),'STRICT_ALL_TABLES','');
      		 
      SELECT e, GROUP_CONCAT(s) FROM t GROUP BY CONVERT((LPAD(e, -1) AND e) USING utf8);
      		 
       
      		 
      # Cleanup
      		 
      DROP TABLE t;

      On some reason, non-strict SQL mode is important here, even though the SELECT doesn't cause any errors or warnings.

      10.4 99c8aed0

      		 
      mysqld: /data/src/10.4/sql/filesort.cc:1003: virtual void Type_handler_string_result::make_sort_key(uchar*, Item*, const SORT_FIELD_ATTR*, Sort_param*) const: Assertion `0' failed.
      		 
      220529  0:00:10 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007f112dc50662 in __GI___assert_fail (assertion=0x55b1d2b560bc "0", file=0x55b1d2b562c0 "/data/src/10.4/sql/filesort.cc", line=1003, function=0x55b1d2b56838 "virtual void Type_handler_string_result::make_sort_key(uchar*, Item*, const SORT_FIELD_ATTR*, Sort_param*) const") at assert.c:101
      		 
      #8  0x000055b1d1ffa79d in Type_handler_string_result::make_sort_key (this=0x55b1d327be10 <type_handler_varchar>, to=0x7f110c05efa8 '\245' <repeats 120 times>, "h4z\025\217\217\217\217\205", item=0x7f110c0160e0, sort_field=0x7f110c019a28, param=0x7f1128421f70) at /data/src/10.4/sql/filesort.cc:1003
      		 
      #9  0x000055b1d1ffb343 in make_sortkey (param=0x7f1128421f70, to=0x7f110c05efa8 '\245' <repeats 120 times>, "h4z\025\217\217\217\217\205", ref_pos=0x7f110c187a50 "") at /data/src/10.4/sql/filesort.cc:1207
      		 
      #10 0x000055b1d1ffa02d in find_all_keys (thd=0x7f110c000d90, param=0x7f1128421f70, select=0x7f110c018bb8, fs_info=0x7f110c097c10, buffpek_pointers=0x7f1128422170, tempfile=0x7f1128422000, pq=0x0, found_rows=0x7f110c097df0) at /data/src/10.4/sql/filesort.cc:845
      		 
      #11 0x000055b1d1ff80a8 in filesort (thd=0x7f110c000d90, table=0x7f110c1a5f30, filesort=0x7f110c0192e0, tracker=0x7f110c0199a0, join=0x7f110c016b48, first_table_bit=1) at /data/src/10.4/sql/filesort.cc:263
      		 
      #12 0x000055b1d1d53e18 in create_sort_index (thd=0x7f110c000d90, join=0x7f110c016b48, tab=0x7f110c018278, fsort=0x7f110c0192e0) at /data/src/10.4/sql/sql_select.cc:23904
      		 
      #13 0x000055b1d1d4df68 in st_join_table::sort_table (this=0x7f110c018278) at /data/src/10.4/sql/sql_select.cc:21624
      		 
      #14 0x000055b1d1d4db49 in join_init_read_record (tab=0x7f110c018278) at /data/src/10.4/sql/sql_select.cc:21563
      		 
      #15 0x000055b1d1d4b859 in sub_select (join=0x7f110c016b48, join_tab=0x7f110c018278, end_of_records=false) at /data/src/10.4/sql/sql_select.cc:20634
      		 
      #16 0x000055b1d1d4ad2b in do_select (join=0x7f110c016b48, procedure=0x0) at /data/src/10.4/sql/sql_select.cc:20173
      		 
      #17 0x000055b1d1d1f674 in JOIN::exec_inner (this=0x7f110c016b48) at /data/src/10.4/sql/sql_select.cc:4545
      		 
      #18 0x000055b1d1d1e784 in JOIN::exec (this=0x7f110c016b48) at /data/src/10.4/sql/sql_select.cc:4327
      		 
      #19 0x000055b1d1d1fefe in mysql_select (thd=0x7f110c000d90, tables=0x7f110c0154b0, wild_num=0, fields=..., conds=0x0, og_num=1, order=0x0, group=0x7f110c0161d0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f110c016b20, unit=0x7f110c004cc0, select_lex=0x7f110c0148a8) at /data/src/10.4/sql/sql_select.cc:4766
      		 
      #20 0x000055b1d1d0f7ec in handle_select (thd=0x7f110c000d90, lex=0x7f110c004c00, result=0x7f110c016b20, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:436
      		 
      #21 0x000055b1d1cd4ed8 in execute_sqlcom_select (thd=0x7f110c000d90, all_tables=0x7f110c0154b0) at /data/src/10.4/sql/sql_parse.cc:6449
      		 
      #22 0x000055b1d1ccb6f8 in mysql_execute_command (thd=0x7f110c000d90) at /data/src/10.4/sql/sql_parse.cc:3963
      		 
      #23 0x000055b1d1cd8e5c in mysql_parse (thd=0x7f110c000d90, rawbuf=0x7f110c0147a8 "SELECT e, GROUP_CONCAT(s) FROM t GROUP BY CONVERT((LPAD(e, -1) AND e) USING utf8)", length=81, parser_state=0x7f1128423550, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7995
      		 
      #24 0x000055b1d1cc52fc in dispatch_command (command=COM_QUERY, thd=0x7f110c000d90, packet=0x7f110c00ac01 "", packet_length=81, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1857
      		 
      #25 0x000055b1d1cc3baf in do_command (thd=0x7f110c000d90) at /data/src/10.4/sql/sql_parse.cc:1378
      		 
      #26 0x000055b1d1e52cbf in do_handle_one_connection (connect=0x55b1d5952440) at /data/src/10.4/sql/sql_connect.cc:1420
      		 
      #27 0x000055b1d1e52967 in handle_one_connection (arg=0x55b1d5952440) at /data/src/10.4/sql/sql_connect.cc:1316
      		 
      #28 0x000055b1d236f5cb in pfs_spawn_thread (arg=0x55b1d59c9e40) at /data/src/10.4/storage/perfschema/pfs.cc:1869
      		 
      #29 0x00007f112e11cea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
      		 
      #30 0x00007f112dd19def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

      Non-debug build doesn't fail (and doesn't produce any ASAN errors), but it exhibits strange behavior more obvious with a bit simpler query:

      CREATE TABLE t (s DATE, e DATE, PERIOD FOR p(s,e));
      		 
      INSERT INTO t (s,e) VALUES ('1970-01-01','1970-01-02'),('1980-01-01','1980-01-02');
      		 
       
      		 
      SET sql_mode=REPLACE(REPLACE(@@sql_mode,'STRICT_TRANS_TABLES',''),'STRICT_ALL_TABLES','');
      		 
      SELECT DISTINCT CONVERT((LPAD(e, -1) AND e) USING utf8) FROM t;
      		 
      SET sql_mode=STRICT_TRANS_TABLES;
      		 
      SELECT DISTINCT CONVERT((LPAD(e, -1) AND e) USING utf8) FROM t;
      		 
       
      		 
      # Cleanup
      		 
      DROP TABLE t;

      10.4 99c8aed0

      		 
      SET sql_mode=REPLACE(REPLACE(@@sql_mode,'STRICT_TRANS_TABLES',''),'STRICT_ALL_TABLES','');
      		 
      SELECT DISTINCT CONVERT((LPAD(e, -1) AND e) USING utf8) FROM t;
      		 
      CONVERT((LPAD(e, -1) AND e) USING utf8)
      		 
       
      		 
      SET sql_mode=STRICT_TRANS_TABLES;
      		 
      SELECT DISTINCT CONVERT((LPAD(e, -1) AND e) USING utf8) FROM t;
      		 
      CONVERT((LPAD(e, -1) AND e) USING utf8)
      		 
      NULL

      That is, the same query in a strict mode returns NULL, while in a non-strict mode – an empty string.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-18770 AddressSanitizer: memcpy-param-overlap in my_strnxfrm_8bit_bin

          • Major - Major loss of function.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. MDEV-29019 Assertion `(length % 4) == 0' failed in my_lengthsp_utf32 on SELECT

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-29283 Assertion `0' failed -or- Assertion `item->maybe_null()' failed - both in virtual void Type_handler_string_result::make_sort_key_part - on UPDATE ... ORDER BY ... LIMIT 0

          • Major - Major loss of function.
          • Confirmed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33392 Server crashes when using RANDOM_BYTES function and GROUP BY clause on a column with a negative value

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            People

              bar Alexander Barkov
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.