Details
Major Description
The scenario is not applicable to 10.5 because of sys schema. Since 10.5 is now EOL, I won't unwrap it.
CREATE VIEW v AS SELECT * FROM sys.x$host_summary; |
SELECT * FROM v WHERE table_scans > DEFAULT(file_io_latency); |
DROP VIEW v; |
|
10.6 c3578720e6b5ef82482a8b4ed57db54c95e34633 |
#4 <signal handler called>
|
#5 0x0000564af1dfb856 in Item_ref::make_send_field (this=0x6310000d5138, thd=0x62b00007e218, field=0x7f603aceac40) at /data/bld/10.6-asan-ubsan/sql/item.cc:8850
|
#6 0x0000564af1dfb908 in Item_ref::make_send_field (this=0x6310000d3800, thd=0x62b00007e218, field=0x7f603aceac40) at /data/bld/10.6-asan-ubsan/sql/item.cc:8850
|
#7 0x0000564af1ca5544 in Send_field::Send_field (this=this@entry=0x7f603aceac40, thd=thd@entry=0x62b00007e218, item=item@entry=0x6310000d3800) at /data/bld/10.6-asan-ubsan/sql/field.cc:11193
|
#8 0x0000564af05dc2b7 in Protocol_text::store_item_metadata (this=this@entry=0x7f603aceae50, thd=<optimized out>, item=item@entry=0x6310000d3800, pos=pos@entry=6) at /data/bld/10.6-asan-ubsan/sql/protocol.cc:1293
|
#9 0x0000564af05dd45a in Protocol::send_result_set_metadata (this=0x62b00007e830, list=<optimized out>, flags=<optimized out>) at /data/bld/10.6-asan-ubsan/sql/protocol.cc:1210
|
#10 0x0000564af08d707e in select_send::send_result_set_metadata (this=this@entry=0x6310000ca288, list=..., flags=flags@entry=3) at /data/bld/10.6-asan-ubsan/sql/sql_class.cc:3173
|
#11 0x0000564af0e6ffa6 in JOIN::exec_inner (this=this@entry=0x6310000ca2b8) at /data/bld/10.6-asan-ubsan/sql/sql_select.cc:4935
|
#12 0x0000564af0e70a18 in JOIN::exec (this=this@entry=0x6310000ca2b8) at /data/bld/10.6-asan-ubsan/sql/sql_select.cc:4717
|
#13 0x0000564af0e673a6 in mysql_select (thd=thd@entry=0x62b00007e218, tables=<optimized out>, fields=..., conds=conds@entry=0x62d00005b658, og_num=og_num@entry=0, order=order@entry=0x0, group=<optimized out>, having=<optimized out>, proc_param=<optimized out>, select_options=<optimized out>, result=<optimized out>, unit=<optimized out>, select_lex=<optimized out>) at /data/bld/10.6-asan-ubsan/sql/sql_select.cc:5196
|
#14 0x0000564af0e68590 in handle_select (thd=thd@entry=0x62b00007e218, lex=lex@entry=0x62b000082538, result=result@entry=0x6310000ca288, setup_tables_done_option=setup_tables_done_option@entry=0) at /data/bld/10.6-asan-ubsan/sql/sql_select.cc:573
|
#15 0x0000564af0b5f2c8 in execute_sqlcom_select (thd=thd@entry=0x62b00007e218, all_tables=<optimized out>) at /data/bld/10.6-asan-ubsan/sql/sql_parse.cc:6422
|
#16 0x0000564af0ba2d52 in mysql_execute_command (thd=thd@entry=0x62b00007e218, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /data/bld/10.6-asan-ubsan/sql/sql_parse.cc:4013
|
#17 0x0000564af0bc4c6c in mysql_parse (thd=thd@entry=0x62b00007e218, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x7f603acecac0) at /data/bld/10.6-asan-ubsan/sql/sql_parse.cc:8200
|
#18 0x0000564af0bcdf3c in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x62b00007e218, packet=packet@entry=0x62900024e219 "", packet_length=packet_length@entry=60, blocking=blocking@entry=true) at /data/bld/10.6-asan-ubsan/sql/sql_parse.cc:1908
|
#19 0x0000564af0bdab8e in do_command (thd=thd@entry=0x62b00007e218, blocking=blocking@entry=true) at /data/bld/10.6-asan-ubsan/sql/sql_parse.cc:1421
|
#20 0x0000564af135aeb0 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x608000002f38, put_in_cache=put_in_cache@entry=true) at /data/bld/10.6-asan-ubsan/sql/sql_connect.cc:1386
|
#21 0x0000564af135c00d in handle_one_connection (arg=0x608000002f38) at /data/bld/10.6-asan-ubsan/sql/sql_connect.cc:1298
|
#22 0x0000564af2d879db in pfs_spawn_thread (arg=0x617000005b98) at /data/bld/10.6-asan-ubsan/storage/perfschema/pfs.cc:2201
|
#23 0x00007f60458a81c4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#24 0x00007f604592885c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
This particular failure started happening after the merge 757c368139ba41de4ccd4c4c8ce3d7c17e4cc3d4, specifically this commit
commit cf202decde475933dfa6b0aadfa5e04e667bfab7
|
Author: Oleg Smirnov
|
Date: Fri Aug 2 18:48:29 2024 +0700
|
|
|
MDEV-34683 Types mismatch when cloning items causes debug assertion
|
That is, it was a debug assertion before the commit, now it is sigsegv.
However these scenarios have been failing constantly in different ways — debug assertions, segmentation faults, etc. – ever since MDEV-34490, so I'm not marking it a regression anymore.