|
CREATE TABLE t1 (a INT, b TEXT NOT NULL DEFAULT '');
|
ALTER TABLE t1 CHARACTER SET = utf8;
|
CREATE TABLE t2 SELECT * FROM t1;
|
INSERT INTO t1 VALUES (1,'');
|
|
# Cleanup
|
DROP TABLE t1, t2;
|
|
10.2 2be617d8
|
#3 <signal handler called>
|
#4 0x0000562331a355e0 in TABLE::mark_default_fields_for_write (this=0x7f46a4035240, is_insert=true) at /data/src/10.2/sql/table.cc:6982
|
#5 0x0000562331a34afd in TABLE::mark_columns_needed_for_insert (this=0x7f46a4035240) at /data/src/10.2/sql/table.cc:6674
|
#6 0x00005623318fc06e in mysql_insert (thd=0x7f46a4000d90, table_list=0x7f46a40127e8, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at /data/src/10.2/sql/sql_insert.cc:909
|
#7 0x0000562331923434 in mysql_execute_command (thd=0x7f46a4000d90) at /data/src/10.2/sql/sql_parse.cc:4217
|
#8 0x000056233192e876 in mysql_parse (thd=0x7f46a4000d90, rawbuf=0x7f46a4012708 "INSERT INTO t1 VALUES (1,'')", length=28, parser_state=0x7f46c04675e0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7793
|
#9 0x000056233191cc19 in dispatch_command (command=COM_QUERY, thd=0x7f46a4000d90, packet=0x7f46a4008b61 "INSERT INTO t1 VALUES (1,'')", packet_length=28, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1827
|
#10 0x000056233191b732 in do_command (thd=0x7f46a4000d90) at /data/src/10.2/sql/sql_parse.cc:1381
|
#11 0x0000562331a735bc in do_handle_one_connection (connect=0x562333e53630) at /data/src/10.2/sql/sql_connect.cc:1336
|
#12 0x0000562331a73330 in handle_one_connection (arg=0x562333e53630) at /data/src/10.2/sql/sql_connect.cc:1241
|
#13 0x000056233227b8d3 in pfs_spawn_thread (arg=0x562333e3f3d0) at /data/src/10.2/storage/perfschema/pfs.cc:1869
|
#14 0x00007f46c5fceea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#15 0x00007f46c5bd3def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
In ASAN it's use-after-poison with pretty much the same stack trace.
The failure started happening after this commit into 10.2:
commit 5ba77222e9fe7af8ff403816b5338b18b342053c
|
Author: Sergei Golubchik
|
Date: Tue Apr 19 17:09:19 2022 +0200
|
|
MDEV-21028 Server crashes in Query_arena::set_query_arena upon SELECT from view
|
|
if the view has algorithm=temptable it is not updatable,
|
It's possible that it only affects 10.2. At least the patch has been merged into 10.3 but the test case doesn't fail there. 10.4+ don't have the patch yet.
|