Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
11.3.2
-
Docker on Windows
Description
This query causes MariaDB to crash:
DELETE
FROM co_instances
USING co_instances INNER JOIN qAllPages qap ON
co_instances.page_ID = qap.page_ID AND
co_instances.istodelete = 1
co_instances is a REAL TABLE. Schema:
CREATE TABLE co_instances (
instance_ID int NOT NULL AUTO_INCREMENT,
page_ID int NOT NULL,
outputtype_ID int NOT NULL,
object_ID int NULL,
location_ID int NOT NULL DEFAULT 0,
lang_ID int NULL,
movedto_ID int NULL,
inheritedfrominstance_ID int NOT NULL DEFAULT 0,
anchorname varchar(50) NULL,
schedstartdate datetime NULL,
schedenddate datetime NULL,
sortorder int NOT NULL DEFAULT 0,
datedeleted datetime NULL,
datepublished datetime NULL,
datecreated datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
dateupdated datetime NULL,
updatenumber int NOT NULL DEFAULT 0,
dynamic smallint NOT NULL DEFAULT 0,
intervaltype smallint NOT NULL DEFAULT 1,
intervalhour smallint NOT NULL DEFAULT 0,
intervaldata varchar(100) NULL,
intervalpublished datetime NULL,
dateinstancechanged datetime NULL,
istodelete tinyint NOT NULL DEFAULT 0,
uniquename varchar(40) NOT NULL,
variablevalues longtext NULL,
instance_stage smallint NOT NULL DEFAULT 100,
PRIMARY KEY (instance_ID) ,
UNIQUE INDEX unico_instances (uniquename ASC),
INDEX XIF17co_instances (object_ID ASC),
INDEX idx_co_inst_inheritedfrom_id (inheritedfrominstance_ID ASC),
INDEX IDX_ins_page_object_ID (page_ID ASC),
INDEX idx_co_inst_location_id (location_ID ASC),
INDEX idx_co_inst_lang_id (lang_ID ASC),
INDEX idx_co_inst_schedend (schedenddate ASC),
INDEX idx_co_inst_schedstart (schedstartdate ASC),
INDEX idx_co_inst_istodelete (istodelete ASC),
INDEX idx_co_inst_movedto_id (movedto_ID ASC),
INDEX idx_co_inst_datedeleted (datedeleted ASC),
INDEX idx_co_inst_instance_stage (instance_stage ASC)
);
qAllPages is a TEMPORARY TABLE. Schema:
CREATE TEMPORARY TABLE qAllPages (folder_ID INT, page_ID INT, page_stage TINYINT, page_approvechange TINYINT, page_cp_ID INT, site_ID INT, page_offline TINYINT, page_update TINYINT, page_online TINYINT, page_offupd TINYINT, page_onlupd TINYINT, page_onloff TINYINT, PRIMARY KEY (page_ID));
Error Details:
2024-02-23 09:47:30 Sorry, we probably made a mistake, and this is a bug.
2024-02-23 09:47:30
2024-02-23 09:47:30 Your assistance in bug reporting will enable us to fix this for the next release.
2024-02-23 09:47:30 To report this bug, see https://mariadb.com/kb/en/reporting-bugs
2024-02-23 09:47:30
2024-02-23 09:47:30 We will try our best to scrape up some info that will hopefully help
2024-02-23 09:47:30 diagnose the problem, but since we have already crashed,
2024-02-23 09:47:30 something is definitely wrong and this may fail.
2024-02-23 09:47:30
2024-02-23 09:47:30 Server version: 11.3.2-MariaDB-1:11.3.2+maria~ubu2204 source revision: 068a6819eb63bcb01fdfa037c9bf3bf63c33ee42
2024-02-23 09:47:30 key_buffer_size=134217728
2024-02-23 09:47:30 read_buffer_size=131072
2024-02-23 09:47:30 max_used_connections=5
2024-02-23 09:47:30 max_threads=153
2024-02-23 09:47:30 thread_count=4
2024-02-23 09:47:30 It is possible that mysqld could use up to
2024-02-23 09:47:30 key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 468064 K bytes of memory
2024-02-23 09:47:30 Hope that's ok; if not, decrease some variables in the equation.
2024-02-23 09:47:30
2024-02-23 09:47:30 Thread pointer: 0x7efdfc000c68
2024-02-23 09:47:30 Attempting backtrace. You can use the following information to find out
2024-02-23 09:47:30 where mysqld died. If you see no messages after this, something went
2024-02-23 09:47:30 terribly wrong...
2024-02-23 09:47:30 stack_bottom = 0x7efe385a8c38 thread_stack 0x49000
2024-02-23 09:47:30 Printing to addr2line failed
2024-02-23 09:47:30 mariadbd(my_print_stacktrace+0x32)[0x563bb6c458a2]
2024-02-23 09:47:30 mariadbd(handle_fatal_signal+0x478)[0x563bb6716488]
2024-02-23 09:47:30 /lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7efe5d086520]
2024-02-23 09:47:30 mariadbd(handler_rowid_filter_check+0x58)[0x563bb6724698]
2024-02-23 09:47:30 mariadbd(+0xe8bae4)[0x563bb6acdae4]
2024-02-23 09:47:30 mariadbd(+0xe8f327)[0x563bb6ad1327]
2024-02-23 09:47:30 mariadbd(+0xdca40c)[0x563bb6a0c40c]
2024-02-23 09:47:30 mariadbd(ZN7handler10ha_rnd_posEPhS0+0x2da)[0x563bb671e2da]
2024-02-23 09:47:30 mariadbd(_Z16rr_from_pointersP11READ_RECORD+0x3c)[0x563bb63c108c]
2024-02-23 09:47:30 mariadbd(_ZN12multi_delete16do_table_deletesEP5TABLEP9SORT_INFOb+0x98)[0x563bb644a988]
2024-02-23 09:47:30 mariadbd(_ZN12multi_delete10do_deletesEv+0x88)[0x563bb644ac48]
2024-02-23 09:47:30 mariadbd(_ZN12multi_delete8send_eofEv+0x75)[0x563bb644ad25]
2024-02-23 09:47:30 mariadbd(_ZN4JOIN10exec_innerEv+0xf56)[0x563bb6517bf6]
2024-02-23 09:47:30 mariadbd(_ZN4JOIN4execEv+0x3f)[0x563bb65180af]
2024-02-23 09:47:30 mariadbd(_ZN11Sql_cmd_dml13execute_innerEP3THD+0x7a)[0x563bb65181da]
2024-02-23 09:47:30 mariadbd(_ZN14Sql_cmd_delete13execute_innerEP3THD+0x2a)[0x563bb644a61a]
2024-02-23 09:47:30 mariadbd(_ZN11Sql_cmd_dml7executeEP3THD+0xc3)[0x563bb64cfd73]
2024-02-23 09:47:30 mariadbd(_Z21mysql_execute_commandP3THDb+0x4911)[0x563bb6498b11]
2024-02-23 09:47:30 mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x1e7)[0x563bb6499b77]
2024-02-23 09:47:30 mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0x14cd)[0x563bb649c36d]
2024-02-23 09:47:30 mariadbd(_Z10do_commandP3THDb+0x138)[0x563bb649e278]
2024-02-23 09:47:30 mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x3bf)[0x563bb65ca7cf]
2024-02-23 09:47:30 mariadbd(handle_one_connection+0x5d)[0x563bb65cab1d]
2024-02-23 09:47:30 mariadbd(+0xd05f86)[0x563bb6947f86]
2024-02-23 09:47:30 /lib/x86_64-linux-gnu/libc.so.6(+0x94ac3)[0x7efe5d0d8ac3]
2024-02-23 09:47:30 /lib/x86_64-linux-gnu/libc.so.6(+0x126850)[0x7efe5d16a850]
2024-02-23 09:47:30
2024-02-23 09:47:30 Trying to get some variables.
2024-02-23 09:47:30 Some pointers may be invalid and cause the dump to abort.
2024-02-23 09:47:30 Query (0x7efdfc010b80): DELETE
2024-02-23 09:47:30 FROM co_instances
2024-02-23 09:47:30 USING co_instances
2024-02-23 09:47:30 INNER JOIN tmp4d45e80bdb464f178a0463be10d94ff3_qAllPages qap ON
2024-02-23 09:47:30 co_instances.page_ID = qap.page_ID AND
2024-02-23 09:47:30 co_instances.istodelete = 1
2024-02-23 09:47:30
2024-02-23 09:47:30 Connection ID (thread ID): 9
2024-02-23 09:47:30 Status: NOT_KILLED
2024-02-23 09:47:30
2024-02-23 09:47:30 Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=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,not_null_range_scan=off,hash_join_cardinality=on,cset_narrowing=off,sargable_casefold=on
2024-02-23 09:47:30
2024-02-23 09:47:30 The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains
2024-02-23 09:47:30 information that should help you find out what is causing the crash.
2024-02-23 09:47:30 Writing a core file...
2024-02-23 09:47:30 Working directory at /var/lib/mysql
2024-02-23 09:47:30 Resource Limits:
2024-02-23 09:47:30 Limit Soft Limit Hard Limit Units
2024-02-23 09:47:30 Max cpu time unlimited unlimited seconds
2024-02-23 09:47:30 Max file size unlimited unlimited bytes
2024-02-23 09:47:30 Max data size unlimited unlimited bytes
2024-02-23 09:47:30 Max stack size 8388608 unlimited bytes
2024-02-23 09:47:30 Max core file size 0 unlimited bytes
2024-02-23 09:47:30 Max resident set unlimited unlimited bytes
2024-02-23 09:47:30 Max processes unlimited unlimited processes
2024-02-23 09:47:30 Max open files 1048576 1048576 files
2024-02-23 09:47:30 Max locked memory 83968000 83968000 bytes
2024-02-23 09:47:30 Max address space unlimited unlimited bytes
2024-02-23 09:47:30 Max file locks unlimited unlimited locks
2024-02-23 09:47:30 Max pending signals 127716 127716 signals
2024-02-23 09:47:30 Max msgqueue size 819200 819200 bytes
2024-02-23 09:47:30 Max nice priority 0 0
2024-02-23 09:47:30 Max realtime priority 0 0
2024-02-23 09:47:30 Max realtime timeout unlimited unlimited us
2024-02-23 09:47:30 Core pattern: /mnt/wslg/dumps/core.%e
2024-02-23 09:47:30
2024-02-23 09:47:30 Kernel version: Linux version 5.15.133.1-microsoft-standard-WSL2 (root@1c602f52c2e4) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-23 09:47:30
Attachments
Issue Links
- duplicates
-
MDEV-33533 Crash at execution of DELETE when trying to use rowid filter
- Closed
- relates to
-
MDEV-27366 SIGSEGV in handler_index_cond_check on SELECT in connection with rowid_filter setting
- In Review