Mark Schmidt (Inactive) added a comment - 2019-12-02 14:43 Can we support you in any way? It has high priority for us.

Oleksandr Byelkin added a comment - 2019-12-02 16:22 The https://mariadb.com/kb/en/library/mariadb-community-bug-reporting/ is the guide to the good bug report, in this particular case repeatable test suite would be really helpful, we see and could guess what is going wrong by stack trace, but still can not easy guess what lead to such state (we will of course). Also your bug report is quite fresh so it is quite far away in the queue (you can check it by sorting my bugs ("assignee = sanja" in advanced search) by priority and date in JIRA, we do not make secret from bugreports as ORACLE do) so you have time.

Mark Schmidt (Inactive) added a comment - 2020-01-09 09:24 Do you have any news for us? Thank You.

Elena Stepanova added a comment - 2023-06-19 21:52 - edited The following test case fails with the same stack trace as the one reported here. I'm not quite sure it represents the exact same use case, as it involves a HEAP table, while the reported ones were InnoDB. Still, the resemblance is remarkable. If it is the same problem, then it apparently stopped happening on 10.5. Hopefully affected instances have long been upgraded and don't encounter it anymore. --source include/have_partition.inc   CREATE TABLE t ( id INT , a datetime, b time , KEY (a) USING BTREE, KEY (b) USING BTREE ) ENGINE=HEAP PARTITION BY key (id) partitions 2;   INSERT INTO t VALUES (1, '0000-00-00' , '00:00:00' ) , (2, '0000-00-00' , '00:00:00' ) , (3, '2017-01-01' , '00:00:00' ) , (4, '1986-01-01' , '00:00:00' ) , (5, '2012-01-01' , '00:00:00' );   SELECT * FROM t WHERE a IS NULL OR b IS NULL ;   # Cleanup DROP TABLE t; 10.4 f5dceafd #3 <signal handler called> #4 0x000055d0a3a6e8d4 in ha_partition::open (this=0x621000093928, name=0x603000014328 "./test/t#P#p0", mode=33, test_if_locked=2) at /data/src/10.4/sql/ha_partition.cc:3569 #5 0x000055d0a328ff48 in handler::ha_open (this=0x621000093928, table_arg=0x62000003c088, name=0x603000014328 "./test/t#P#p0", mode=33, test_if_locked=2, mem_root=0x0, partitions_to_open=0x0) at /data/src/10.4/sql/handler.cc:2808 #6 0x000055d0a3bf5aaa in ha_heap::clone (this=0x61a00002dca8, name=0x7f54366a9960 "./test/t#P#p0", mem_root=0x61100002c948) at /data/src/10.4/storage/heap/ha_heap.cc:153 #7 0x000055d0a3a6fb4b in ha_partition::open (this=0x621000092798, name=0x61b00003a938 "./test/t", mode=33, test_if_locked=1026) at /data/src/10.4/sql/ha_partition.cc:3664 #8 0x000055d0a328ff48 in handler::ha_open (this=0x621000092798, table_arg=0x62000003c088, name=0x61b00003a938 "./test/t", mode=33, test_if_locked=1026, mem_root=0x0, partitions_to_open=0x0) at /data/src/10.4/sql/handler.cc:2808 #9 0x000055d0a3a70fc5 in ha_partition::clone (this=0x61d0002058a8, name=0x61b00003a938 "./test/t", mem_root=0x61100002c948) at /data/src/10.4/sql/ha_partition.cc:3844 #10 0x000055d0a3635b4c in QUICK_RANGE_SELECT::init_ror_merged_scan (this=0x613000050d80, reuse_handler=false, local_alloc=0x61100002c948) at /data/src/10.4/sql/opt_range.cc:1523 #11 0x000055d0a36383b6 in QUICK_ROR_UNION_SELECT::reset (this=0x61100002c8c0) at /data/src/10.4/sql/opt_range.cc:1803 #12 0x000055d0a2c2ad50 in join_init_read_record (tab=0x62b0000662a8) at /data/src/10.4/sql/sql_select.cc:21820 #13 0x000055d0a2c24323 in sub_select (join=0x62b000063f00, join_tab=0x62b0000662a8, end_of_records=false) at /data/src/10.4/sql/sql_select.cc:20886 #14 0x000055d0a2c2232e in do_select (join=0x62b000063f00, procedure=0x0) at /data/src/10.4/sql/sql_select.cc:20412 #15 0x000055d0a2bb11bd in JOIN::exec_inner (this=0x62b000063f00) at /data/src/10.4/sql/sql_select.cc:4605 #16 0x000055d0a2bae7c4 in JOIN::exec (this=0x62b000063f00) at /data/src/10.4/sql/sql_select.cc:4387 #17 0x000055d0a2bb2856 in mysql_select (thd=0x62b00005b208, tables=0x62b000062938, wild_num=1, fields=..., conds=0x62b000063448, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x62b000063ed0, unit=0x62b00005f140, select_lex=0x62b0000622f0) at /data/src/10.4/sql/sql_select.cc:4826 #18 0x000055d0a2b83461 in handle_select (thd=0x62b00005b208, lex=0x62b00005f080, result=0x62b000063ed0, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:442 #19 0x000055d0a2af328b in execute_sqlcom_select (thd=0x62b00005b208, all_tables=0x62b000062938) at /data/src/10.4/sql/sql_parse.cc:6473 #20 0x000055d0a2ae07a0 in mysql_execute_command (thd=0x62b00005b208) at /data/src/10.4/sql/sql_parse.cc:3976 #21 0x000055d0a2afc463 in mysql_parse (thd=0x62b00005b208, rawbuf=0x62b000062228 "SELECT * FROM t WHERE a IS NULL OR b IS NULL", length=44, parser_state=0x7f54366ac860, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8008 #22 0x000055d0a2ad27a6 in dispatch_command (command=COM_QUERY, thd=0x62b00005b208, packet=0x629000230209 "", packet_length=44, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1857 #23 0x000055d0a2acf315 in do_command (thd=0x62b00005b208) at /data/src/10.4/sql/sql_parse.cc:1378 #24 0x000055d0a2ece0ba in do_handle_one_connection (connect=0x6080000009a8) at /data/src/10.4/sql/sql_connect.cc:1420 #25 0x000055d0a2ecd9d1 in handle_one_connection (arg=0x6080000009a8) at /data/src/10.4/sql/sql_connect.cc:1324 #26 0x000055d0a3b3aaee in pfs_spawn_thread (arg=0x615000003508) at /data/src/10.4/storage/perfschema/pfs.cc:1869 #27 0x00007f543e4a7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 #28 0x00007f543e5285bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Elena Stepanova added a comment - 2024-10-05 18:42 10.4 is EOL, and the above test case doesn't fail on 10.5+.