[MDEV-25056] Server crash in Protocol::net_store_data or corrupt result set upon SELECT with ORDER BY virtual column - Jira

XML

Word

Printable

Details

Type: Bug
Status: Open (View Workflow)
Priority: Major
Resolution: Unresolved
Affects Version/s: 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
Fix Version/s: 10.5
Component/s: Protocol, Virtual Columns
Labels:
None

Description

Note: The failure is non-deterministic, run with --repeat=N. It currently crashes for me within a few attempts on an ASAN build and returns a garbage result on a non-ASAN debug build; but it can vary on different machines.

--source include/have_innodb.inc

--source include/have_sequence.inc

CREATE TABLE t1 (a VARCHAR(3814), b VARCHAR(3814) AS (a) VIRTUAL) ENGINE=InnoDB CHARSET=latin1;

INSERT INTO t1 (a) SELECT NULL FROM seq_1_to_2000;

SELECT * FROM t1 ORDER BY b;

# Cleanup

DROP TABLE t1;

10.2 676987c4
==1079800==ERROR: AddressSanitizer: unknown-crash on address 0x62800001def9 at pc 0x7ff3f86a4480 bp 0x7ff3e173bc00 sp 0x7ff3e173b3a8
READ of size 48830 at 0x62800001def9 thread T27
#0 0x7ff3f86a447f (/lib/x86_64-linux-gnu/libasan.so.5+0x9b47f)
#1 0x5594b3cb1c32 in Protocol::net_store_data(unsigned char const*, unsigned long) /data/src/10.2-bug/sql/protocol.cc:61
#2 0x5594b3cb84c6 in Protocol_text::store(Field*) /data/src/10.2-bug/sql/protocol.cc:1262
#3 0x5594b3cb52c1 in Protocol::send_result_set_row(List<Item>*) /data/src/10.2-bug/sql/protocol.cc:990
#4 0x5594b3dae556 in select_send::send_data(List<Item>&) /data/src/10.2-bug/sql/sql_class.cc:2726
#5 0x5594b3f5123c in end_send /data/src/10.2-bug/sql/sql_select.cc:20003
#6 0x5594b3ee647b in evaluate_join_record /data/src/10.2-bug/sql/sql_select.cc:19051
#7 0x5594b3f0344a in sub_select(JOIN, st_join_table, bool) /data/src/10.2-bug/sql/sql_select.cc:18831
#8 0x5594b3f0344a in sub_select(JOIN, st_join_table, bool) /data/src/10.2-bug/sql/sql_select.cc:18766
#9 0x5594b3f90938 in do_select /data/src/10.2-bug/sql/sql_select.cc:18375
#10 0x5594b3f90938 in JOIN::exec_inner() /data/src/10.2-bug/sql/sql_select.cc:3627
#11 0x5594b3f91b5f in JOIN::exec() /data/src/10.2-bug/sql/sql_select.cc:3422
#12 0x5594b3f91f4c in mysql_select(THD, TABLE_LIST, unsigned int, List<Item>&, Item, unsigned int, st_order, st_order, Item, st_order, unsigned long long, select_result, st_select_lex_unit, st_select_lex) /data/src/10.2-bug/sql/sql_select.cc:3822
#13 0x5594b3f94764 in handle_select(THD, LEX, select_result*, unsigned long) /data/src/10.2-bug/sql/sql_select.cc:365
#14 0x5594b3e34554 in execute_sqlcom_select /data/src/10.2-bug/sql/sql_parse.cc:6226
#15 0x5594b3e6104c in mysql_execute_command(THD*) /data/src/10.2-bug/sql/sql_parse.cc:3533
#16 0x5594b3e696e7 in mysql_parse(THD, char, unsigned int, Parser_state*, bool, bool) /data/src/10.2-bug/sql/sql_parse.cc:7760
#17 0x5594b3e74f24 in dispatch_command(enum_server_command, THD, char, unsigned int, bool, bool) /data/src/10.2-bug/sql/sql_parse.cc:1831
#18 0x5594b3e780ad in do_command(THD*) /data/src/10.2-bug/sql/sql_parse.cc:1385
#19 0x5594b415865a in do_handle_one_connection(CONNECT*) /data/src/10.2-bug/sql/sql_connect.cc:1336
#20 0x5594b4158d50 in handle_one_connection /data/src/10.2-bug/sql/sql_connect.cc:1241
#21 0x5594b5449ad7 in pfs_spawn_thread /data/src/10.2-bug/storage/perfschema/pfs.cc:1862
#22 0x7ff3f814b608 in start_thread /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477
#23 0x7ff3f7d27292 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)

0x62800001fcd8 is located 0 bytes to the right of 15320-byte region [0x62800001c100,0x62800001fcd8)
allocated by thread T27 here:
#0 0x7ff3f8716bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#1 0x5594b54fce55 in my_malloc /data/src/10.2-bug/mysys/my_malloc.c:101

Thread T27 created by T0 here:
#0 0x7ff3f8643805 in pthread_create (/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
#1 0x5594b5452737 in spawn_thread_v1 /data/src/10.2-bug/storage/perfschema/pfs.cc:1912

SUMMARY: AddressSanitizer: unknown-crash (/lib/x86_64-linux-gnu/libasan.so.5+0x9b47f)
Shadow bytes around the buggy address:
0x0c507fffbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fffbb90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fffbba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fffbbb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fffbbc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c507fffbbd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[01]
0x0c507fffbbe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fffbbf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fffbc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fffbc10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fffbc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==1079800==ABORTING

The stack trace can vary a bit, probably depending on exact server settings; for example here is one from a non-MTR run on 10.4 with default options (as opposed to the one above which is from MTR on 10.2):

10.4 82efe4a1
==1078255==ERROR: AddressSanitizer: unknown-crash on address 0x62800022df61 at pc 0x562c8ca21710 bp 0x7f5af98b1e10 sp 0x7f5af98b1e00
READ of size 1 at 0x62800022df61 thread T31
#0 0x562c8ca2170f in my_mb_wc_latin1 /data/src/10.4/strings/ctype-latin1.c:372
#1 0x562c8ca8a184 in my_convert_using_func /data/src/10.4/strings/ctype.c:1019
#2 0x562c8ca8a7f1 in my_convert /data/src/10.4/strings/ctype.c:1127
#3 0x562c8ab15c6a in copy_and_convert(char, unsigned long, charset_info_st const, char const, unsigned long, charset_info_st const, unsigned int*) /data/src/10.4/sql/sql_string.h:44
#4 0x562c8affc7dd in String::copy(char const, unsigned long, charset_info_st const, charset_info_st const, unsigned int) /data/src/10.4/sql/sql_string.cc:456
#5 0x562c8ab08d23 in Protocol::net_store_data_cs(unsigned char const, unsigned long, charset_info_st const, charset_info_st const*) /data/src/10.4/sql/protocol.cc:105
#6 0x562c8ab1012e in Protocol::store_string_aux(char const, unsigned long, charset_info_st const, charset_info_st const*) /data/src/10.4/sql/protocol.cc:1141
#7 0x562c8ab11d50 in Protocol_text::store(Field*) /data/src/10.4/sql/protocol.cc:1283
#8 0x562c8b65751e in Item_field::send(Protocol, st_value) /data/src/10.4/sql/item.cc:7150
#9 0x562c8ab0f70e in Protocol::send_result_set_row(List<Item>*) /data/src/10.4/sql/protocol.cc:1037
#10 0x562c8acb9f02 in select_send::send_data(List<Item>&) /data/src/10.4/sql/sql_class.cc:3007
#11 0x562c8af1ee7a in end_send /data/src/10.4/sql/sql_select.cc:21595
#12 0x562c8af1725f in evaluate_join_record /data/src/10.4/sql/sql_select.cc:20626
#13 0x562c8af15c25 in sub_select(JOIN, st_join_table, bool) /data/src/10.4/sql/sql_select.cc:20406
#14 0x562c8af13dcf in do_select /data/src/10.4/sql/sql_select.cc:19944
#15 0x562c8aea3aec in JOIN::exec_inner() /data/src/10.4/sql/sql_select.cc:4487
#16 0x562c8aea10f9 in JOIN::exec() /data/src/10.4/sql/sql_select.cc:4269
#17 0x562c8aea526c in mysql_select(THD, TABLE_LIST, unsigned int, List<Item>&, Item, unsigned int, st_order, st_order, Item, st_order, unsigned long long, select_result, st_select_lex_unit, st_select_lex) /data/src/10.4/sql/sql_select.cc:4704
#18 0x562c8ae76735 in handle_select(THD, LEX, select_result*, unsigned long) /data/src/10.4/sql/sql_select.cc:410
#19 0x562c8ade63dc in execute_sqlcom_select /data/src/10.4/sql/sql_parse.cc:6418
#20 0x562c8add3b73 in mysql_execute_command(THD*) /data/src/10.4/sql/sql_parse.cc:3937
#21 0x562c8adef874 in mysql_parse(THD, char, unsigned int, Parser_state*, bool, bool) /data/src/10.4/sql/sql_parse.cc:7959
#22 0x562c8adc6371 in dispatch_command(enum_server_command, THD, char, unsigned int, bool, bool) /data/src/10.4/sql/sql_parse.cc:1855
#23 0x562c8adc2e20 in do_command(THD*) /data/src/10.4/sql/sql_parse.cc:1373
#24 0x562c8b1b5517 in do_handle_one_connection(CONNECT*) /data/src/10.4/sql/sql_connect.cc:1412
#25 0x562c8b1b4dbb in handle_one_connection /data/src/10.4/sql/sql_connect.cc:1316
#26 0x7f5b27cdd608 in start_thread /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477
#27 0x7f5b27548292 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)

0x62800022df61 is located 7777 bytes inside of 15428-byte region [0x62800022c100,0x62800022fd44)
allocated by thread T31 here:
#0 0x7f5b27f37bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#1 0x562c8c9c1896 in sf_malloc /data/src/10.4/mysys/safemalloc.c:118
#2 0x562c8c98f6fa in my_malloc /data/src/10.4/mysys/my_malloc.c:101
#3 0x562c8c96b1a8 in alloc_root /data/src/10.4/mysys/my_alloc.c:251
#4 0x562c8b0e39a1 in open_table_from_share(THD, TABLE_SHARE, st_mysql_const_lex_string const, unsigned int, unsigned int, unsigned int, TABLE, bool, List<String>*) /data/src/10.4/sql/table.cc:3701
#5 0x562c8ac3f063 in open_table(THD, TABLE_LIST, Open_table_context*) /data/src/10.4/sql/sql_base.cc:2095
#6 0x562c8ac48ad9 in open_and_process_table /data/src/10.4/sql/sql_base.cc:3905
#7 0x562c8ac4b62d in open_tables(THD, DDL_options_st const&, TABLE_LIST, unsigned int, unsigned int, Prelocking_strategy*) /data/src/10.4/sql/sql_base.cc:4377
#8 0x562c8ac50755 in open_and_lock_tables(THD, DDL_options_st const&, TABLE_LIST, bool, unsigned int, Prelocking_strategy*) /data/src/10.4/sql/sql_base.cc:5313
#9 0x562c8abaadad in open_and_lock_tables(THD, TABLE_LIST, bool, unsigned int) /data/src/10.4/sql/sql_base.h:503
#10 0x562c8add8611 in mysql_execute_command(THD*) /data/src/10.4/sql/sql_parse.cc:4651
#11 0x562c8adef874 in mysql_parse(THD, char, unsigned int, Parser_state*, bool, bool) /data/src/10.4/sql/sql_parse.cc:7959
#12 0x562c8adc6371 in dispatch_command(enum_server_command, THD, char, unsigned int, bool, bool) /data/src/10.4/sql/sql_parse.cc:1855
#13 0x562c8adc2e20 in do_command(THD*) /data/src/10.4/sql/sql_parse.cc:1373
#14 0x562c8b1b5517 in do_handle_one_connection(CONNECT*) /data/src/10.4/sql/sql_connect.cc:1412
#15 0x562c8b1b4dbb in handle_one_connection /data/src/10.4/sql/sql_connect.cc:1316
#16 0x7f5b27cdd608 in start_thread /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477

Thread T31 created by T0 here:
#0 0x7f5b27e64805 in pthread_create (/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
#1 0x562c8c9f48ea in spawn_thread_noop /data/src/10.4/mysys/psi_noop.c:187
#2 0x562c8aaccaff in inline_mysql_thread_create /data/src/10.4/include/mysql/psi/mysql_thread.h:1275
#3 0x562c8aae44b5 in create_thread_to_handle_connection(CONNECT*) /data/src/10.4/sql/mysqld.cc:6243
#4 0x562c8aae4c50 in create_new_thread(CONNECT*) /data/src/10.4/sql/mysqld.cc:6313
#5 0x562c8aae5136 in handle_accepted_socket(st_mysql_socket, st_mysql_socket) /data/src/10.4/sql/mysqld.cc:6411
#6 0x562c8aae5fcf in handle_connections_sockets() /data/src/10.4/sql/mysqld.cc:6569
#7 0x562c8aae3bba in mysqld_main(int, char**) /data/src/10.4/sql/mysqld.cc:5901
#8 0x562c8aacad4c in main /data/src/10.4/sql/main.cc:25
#9 0x7f5b2744d0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

SUMMARY: AddressSanitizer: unknown-crash /data/src/10.4/strings/ctype-latin1.c:372 in my_mb_wc_latin1
Shadow bytes around the buggy address:
0x0c508003db90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c508003dba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c508003dbb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c508003dbc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c508003dbd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c508003dbe0: 00 00 00 00 00 00 00 00 00 00 00 00[01]00 00 00
0x0c508003dbf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c508003dc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c508003dc10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c508003dc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c508003dc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==1078255==ABORTING
210304 20:37:40 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.4.19-MariaDB-debug
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=1
max_threads=153
thread_count=6
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467865 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x62b00009a270
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7f5af98b69e0 thread_stack 0x5fc00
/lib/x86_64-linux-gnu/libasan.so.5(+0x6cd30)[0x7f5b27e96d30]
/data/bld/10.4-asan-nightly/bin/mysqld(my_print_stacktrace+0xec)[0x562c8c99f59c]
/data/bld/10.4-asan-nightly/bin/mysqld(handle_fatal_signal+0xa1a)[0x562c8b5cd05f]
sigaction.c:0(__restore_rt)[0x7f5b27ce93c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f5b2746c18b]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f5b2744b859]
/lib/x86_64-linux-gnu/libasan.so.5(+0x12b6a2)[0x7f5b27f556a2]
/lib/x86_64-linux-gnu/libasan.so.5(+0x13624c)[0x7f5b27f6024c]
/lib/x86_64-linux-gnu/libasan.so.5(+0x1178ec)[0x7f5b27f418ec]
/lib/x86_64-linux-gnu/libasan.so.5(+0x117363)[0x7f5b27f41363]
/lib/x86_64-linux-gnu/libasan.so.5(__asan_report_load1+0x3b)[0x7f5b27f41e4b]
strings/ctype-latin1.c:372(my_mb_wc_latin1)[0x562c8ca21710]
strings/ctype.c:1019(my_convert_using_func)[0x562c8ca8a185]
strings/ctype.c:1127(my_convert)[0x562c8ca8a7f2]
sql/sql_string.h:44(copy_and_convert(char, unsigned long, charset_info_st const, char const, unsigned long, charset_info_st const, unsigned int*))[0x562c8ab15c6b]
sql/sql_string.cc:456(String::copy(char const, unsigned long, charset_info_st const, charset_info_st const, unsigned int))[0x562c8affc7de]
sql/protocol.cc:106(Protocol::net_store_data_cs(unsigned char const, unsigned long, charset_info_st const, charset_info_st const*))[0x562c8ab08d24]
sql/protocol.cc:1141(Protocol::store_string_aux(char const, unsigned long, charset_info_st const, charset_info_st const*))[0x562c8ab1012f]
sql/protocol.cc:1283(Protocol_text::store(Field*))[0x562c8ab11d51]
sql/item.cc:7151(Item_field::send(Protocol, st_value))[0x562c8b65751f]
sql/protocol.cc:1037(Protocol::send_result_set_row(List<Item>*))[0x562c8ab0f70f]
sql/sql_class.cc:3007(select_send::send_data(List<Item>&))[0x562c8acb9f03]
sql/sql_select.cc:21595(end_send(JOIN, st_join_table, bool))[0x562c8af1ee7b]
sql/sql_select.cc:20626(evaluate_join_record(JOIN, st_join_table, int))[0x562c8af17260]
sql/sql_select.cc:20406(sub_select(JOIN, st_join_table, bool))[0x562c8af15c26]
sql/sql_select.cc:19944(do_select(JOIN, Procedure))[0x562c8af13dd0]
sql/sql_select.cc:4487(JOIN::exec_inner())[0x562c8aea3aed]
sql/sql_select.cc:4270(JOIN::exec())[0x562c8aea10fa]
sql/sql_select.cc:4706(mysql_select(THD, TABLE_LIST, unsigned int, List<Item>&, Item, unsigned int, st_order, st_order, Item, st_order, unsigned long long, select_result, st_select_lex_unit, st_select_lex))[0x562c8aea526d]
sql/sql_select.cc:410(handle_select(THD, LEX, select_result*, unsigned long))[0x562c8ae76736]
sql/sql_parse.cc:6418(execute_sqlcom_select(THD, TABLE_LIST))[0x562c8ade63dd]
sql/sql_parse.cc:3937(mysql_execute_command(THD*))[0x562c8add3b74]
sql/sql_parse.cc:7959(mysql_parse(THD, char, unsigned int, Parser_state*, bool, bool))[0x562c8adef875]
sql/sql_parse.cc:1858(dispatch_command(enum_server_command, THD, char, unsigned int, bool, bool))[0x562c8adc6372]
sql/sql_parse.cc:1373(do_command(THD*))[0x562c8adc2e21]
sql/sql_connect.cc:1412(do_handle_one_connection(CONNECT*))[0x562c8b1b5518]
sql/sql_connect.cc:1317(handle_one_connection)[0x562c8b1b4dbc]
nptl/pthread_create.c:478(start_thread)[0x7f5b27cdd609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7f5b27548293]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x62b0000a1290): SELECT * FROM t1 ORDER BY b

Connection ID (thread ID): 11
Status: NOT_KILLED

Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on

The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /data/bld/10.4-asan-nightly/data
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 385874 385874 processes
Max open files 32198 32198 files
Max locked memory 67108864 67108864 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 385874 385874 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Core pattern: \|/usr/share/apport/apport %p %s %c %d %P %E

The corrupt result is too long and too broken to paste in JIRA, it's just a long output of binary garbage.

Reproducible on 10.2-10.5

Attachments

Issue Links

relates to

MDEV-28663 Wrong data from Virtual Column by ordering on a SET

Confirmed

Activity

People

Assignee:: Nikita Malyavin

Reporter:: Elena Stepanova

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: 2021-03-04 18:50

Updated:: 2024-09-10 15:05

Git Integration

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