Details
Blocker Description
Note: The query in the test case doesn't look meaningful, but I'm not sure the problem is limited to such nonsensical queries. If the analysis shows that it indeed does, I don't object demoting it from a blocker.
CREATE TABLE t (f INT); |
INSERT INTO t VALUES (1),(2); |
SELECT DISTINCT CONVERT(STDDEV(f), CHAR(16)) AS f1, UUID() AS f2 FROM t GROUP BY f2 WITH ROLLUP; |
|
|
# Cleanup
|
DROP TABLE t; |
|
10.4 2e1c532b |
#3 <signal handler called>
|
#4 0x0000559fad00b719 in store_length (to=0x7f74ae61d3f9 <error: Cannot access memory at address 0x7f74ae61d3f9>, length=6, pack_length=2779096485) at /data/src/10.4/sql/filesort.cc:970
|
#5 0x0000559fad00ba35 in Type_handler_string_result::make_sort_key (this=0x559fae437f10 <type_handler_varchar>, to=0x7f745407798e '\245' <repeats 200 times>..., item=0x7f7454015018, sort_field=0x7f7454155fa0, tmp_buffer=0x7f7464b72e60) at /data/src/10.4/sql/filesort.cc:1037
|
#6 0x0000559facd47ea9 in make_sort_key (sortorder=0x7f7454155fa0, key_buffer=0x7f745407798d "\001", '\245' <repeats 199 times>..., tmp_value=0x7f7464b72e60) at /data/src/10.4/sql/sql_select.cc:24322
|
#7 0x0000559facd488bc in remove_dup_with_hash_index (thd=0x7f7454000da0, table=0x7f74540537d8, field_count=1, first_field=0x7f7454054b58, sortorder=0x7f7454155fa0, key_length=126, having=0x0) at /data/src/10.4/sql/sql_select.cc:24534
|
#8 0x0000559facd47d30 in st_join_table::remove_duplicates (this=0x7f74540180f8) at /data/src/10.4/sql/sql_select.cc:24296
|
#9 0x0000559facd40fb2 in join_init_read_record (tab=0x7f74540180f8) at /data/src/10.4/sql/sql_select.cc:21753
|
#10 0x0000559facd578ed in AGGR_OP::end_send (this=0x7f7454019210) at /data/src/10.4/sql/sql_select.cc:29577
|
#11 0x0000559facd3e731 in sub_select_postjoin_aggr (join=0x7f7454016420, join_tab=0x7f74540180f8, end_of_records=true) at /data/src/10.4/sql/sql_select.cc:20544
|
#12 0x0000559facd3eaaf in sub_select (join=0x7f7454016420, join_tab=0x7f7454017d50, end_of_records=true) at /data/src/10.4/sql/sql_select.cc:20779
|
#13 0x0000559facd3e751 in sub_select_postjoin_aggr (join=0x7f7454016420, join_tab=0x7f7454017d50, end_of_records=true) at /data/src/10.4/sql/sql_select.cc:20546
|
#14 0x0000559facd3eaaf in sub_select (join=0x7f7454016420, join_tab=0x7f74540179a8, end_of_records=true) at /data/src/10.4/sql/sql_select.cc:20779
|
#15 0x0000559facd3e16a in do_select (join=0x7f7454016420, procedure=0x0) at /data/src/10.4/sql/sql_select.cc:20368
|
#16 0x0000559facd1173c in JOIN::exec_inner (this=0x7f7454016420) at /data/src/10.4/sql/sql_select.cc:4590
|
#17 0x0000559facd10810 in JOIN::exec (this=0x7f7454016420) at /data/src/10.4/sql/sql_select.cc:4372
|
#18 0x0000559facd1200f in mysql_select (thd=0x7f7454000da0, tables=0x7f7454015260, wild_num=0, fields=..., conds=0x0, og_num=1, order=0x0, group=0x7f7454015a80, having=0x0, proc_param=0x0, select_options=2147748609, result=0x7f74540163f8, unit=0x7f7454004cd8, select_lex=0x7f7454014900) at /data/src/10.4/sql/sql_select.cc:4811
|
#19 0x0000559facd00ddf in handle_select (thd=0x7f7454000da0, lex=0x7f7454004c18, result=0x7f74540163f8, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:442
|
#20 0x0000559faccc3c0e in execute_sqlcom_select (thd=0x7f7454000da0, all_tables=0x7f7454015260) at /data/src/10.4/sql/sql_parse.cc:6463
|
#21 0x0000559faccba110 in mysql_execute_command (thd=0x7f7454000da0) at /data/src/10.4/sql/sql_parse.cc:3966
|
#22 0x0000559faccc7d83 in mysql_parse (thd=0x7f7454000da0, rawbuf=0x7f74540147e8 "SELECT DISTINCT CONVERT(STDDEV(f), CHAR(16)) AS f1, UUID() AS f2 FROM t GROUP BY f2 WITH ROLLUP", length=95, parser_state=0x7f7464b743c0, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7998
|
#23 0x0000559faccb37b5 in dispatch_command (command=COM_QUERY, thd=0x7f7454000da0, packet=0x7f745400ac41 "", packet_length=95, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1857
|
#24 0x0000559faccb201c in do_command (thd=0x7f7454000da0) at /data/src/10.4/sql/sql_parse.cc:1378
|
#25 0x0000559face529ca in do_handle_one_connection (connect=0x559fb0eefa00) at /data/src/10.4/sql/sql_connect.cc:1420
|
#26 0x0000559face52732 in handle_one_connection (arg=0x559fb0eefa00) at /data/src/10.4/sql/sql_connect.cc:1324
|
#27 0x0000559fad3a2a48 in pfs_spawn_thread (arg=0x559fb0f35930) at /data/src/10.4/storage/perfschema/pfs.cc:1869
|
#28 0x00007f746abc8fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#29 0x00007f746ac495bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
The failure started happening on 10.4+ after this commit:
commit 476b24d084e7e717310155bb986eb086d3c1e1a6
|
Author: Monty
|
Date: Thu Feb 16 14:19:33 2023 +0200
|
|
|
MDEV-20057 Distinct SUM on CROSS JOIN and grouped returns wrong result
|
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | Open [ 1 ] | In Progress [ 3 ] |
The problem starts here:
#0 Type_handler_string_result::make_sort_key (this=0x5555575aeef0 <type_handler_varchar>, to=0x7fffd40ba68e '\245' <repeats 200 times>..., item=0x7fffd4017168, sort_field=0x7fffd409cca0, tmp_buffer=0x7fffeb548eb0) at /home/psergey/dev-git2/10.4-look/sql/filesort.cc:1026
|
#1 0x0000555555e1f4b8 in make_sort_key (sortorder=0x7fffd409cca0, key_buffer=0x7fffd40ba68d "\001", '\245' <repeats 199 times>..., tmp_value=0x7fffeb548eb0) at /home/psergey/dev-git2/10.4-look/sql/sql_select.cc:24322
|
#2 0x0000555555e1fe9e in remove_dup_with_hash_index (thd=0x7fffd4000d50, table=0x7fffd40787a8, field_count=1, first_field=0x7fffd4079b28, sortorder=0x7fffd409cca0, key_length=126, having=0x0) at /home/psergey/dev-git2/10.4-look/sql/sql_select.cc:24534
|
#3 0x0000555555e1f335 in st_join_table::remove_duplicates (this=0x7fffd401a248) at /home/psergey/dev-git2/10.4-look/sql/sql_select.cc:24296
|
We crash because of non-sensical value:
(gdb) print sort_field_length
|
$26 = 1515870827
|
Which comes from
uint sort_field_length= sort_field->length - sort_field->suffix_length;
|
where
(gdb) p sort_field->length
|
$23 = 16
|
(gdb) p sort_field->suffix_length
|
$24 = 2779096485
|
(gdb) p/x sort_field->suffix_length
|
$25 = 0xa5a5a5a5
|
Doesn't seem to be directly related to MDEV-20057 .
I see a mismatch between
Type_handler_string_result::make_sort_key() and Type_handler_string_result::sortlength().
We use collation latin1_swedish_ci. latin1_swedish_ci!= &my_charset_bin but also for ituse_strnxfrm(...)= false, so Type_handler_string_result::sortlength() function doesn't set suffix_length.
But the code in Type_handler_string_result::make_sort_key() will try to read suffix_length if use_strnxfrm(cs)==false.
oleg.smirnov, can you check the above reasoning. Any clue? Please ask bar if necessary.
| Assignee | Sergei Petrunia [ psergey ] | Oleg Smirnov [ JIRAUSER50405 ] |
| Assignee | Oleg Smirnov [ JIRAUSER50405 ] | Sergei Petrunia [ psergey ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
oleg.smirnov, please make Type_handler_string_result::sortlength() to assign suffix_length in all cases when Type_handler_string_result::make_sort_key() needs it.
That way, the code will be structured better.
| Assignee | Sergei Petrunia [ psergey ] | Oleg Smirnov [ JIRAUSER50405 ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
An alternative, more future proof patch, is the following (in the same function):
+ if (!(sortorder= (SORT_FIELD*) my_malloc((fields->elements+1) *
+ sizeof(SORT_FIELD),
+ MYF(MY_WME))))
Add MY_ZEROFILL to MY_WME above.
| Status | Stalled [ 10000 ] | In Progress [ 3 ] |
After discussion during an optimizer call we decided to proceed with the bzero() approach.
| Assignee | Oleg Smirnov [ JIRAUSER50405 ] | Sergei Petrunia [ psergey ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
| Assignee | Sergei Petrunia [ psergey ] | Oleg Smirnov [ JIRAUSER50405 ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Fix Version/s | 10.8 [ 26121 ] |
| Fix Version/s | 10.4.29 [ 28510 ] | |
| Fix Version/s | 10.5.20 [ 28512 ] | |
| Fix Version/s | 10.6.13 [ 28514 ] | |
| Fix Version/s | 10.9.6 [ 28520 ] | |
| Fix Version/s | 10.10.4 [ 28522 ] | |
| Fix Version/s | 10.11.3 [ 28524 ] | |
| Fix Version/s | 11.1.1 [ 28704 ] | |
| Fix Version/s | 10.8.8 [ 28518 ] | |
| Fix Version/s | 11.0.2 [ 28706 ] | |
| Fix Version/s | 10.4 [ 22408 ] | |
| Fix Version/s | 10.5 [ 23123 ] | |
| Fix Version/s | 10.6 [ 24028 ] | |
| Fix Version/s | 10.9 [ 26905 ] | |
| Fix Version/s | 10.10 [ 27530 ] | |
| Fix Version/s | 10.11 [ 27614 ] | |
| Fix Version/s | 11.0 [ 28320 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Link |
This issue relates to |
| Link |
This issue relates to |
I suppose this failure is related to the initially reported:
mysqld: /home/vsts/src/sql/filesort.cc:2144: virtual void Type_handler_string_result::sort_length(THD*, const Type_std_attributes*, SORT_FIELD_ATTR*) const: Assertion `sortorder->length <= 0xFFFFFFFFL - sortorder->suffix_length' failed.230424 6:58:39 [ERROR] mysqld got signal 6 ;