Details
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
-
MDEV-18770 AddressSanitizer: memcpy-param-overlap in my_strnxfrm_8bit_bin
- Open
-
MDEV-29019 Assertion `(length % 4) == 0' failed in my_lengthsp_utf32 on SELECT
- Closed
-
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
- Confirmed
-
MDEV-33392 Server crashes when using RANDOM_BYTES function and GROUP BY clause on a column with a negative value
- Closed