Pon Suresh Pandian (Inactive) added a comment - 2021-11-30 17:07 Hi Julien, I have tested this issue in my environment, I cant able to re produce this issue. Here I have attached the DDL/DML file. MariaDB [test]> select count (*) from alf_node; + ----------+ | count (*) | + ----------+ | 321777 | + ----------+ 1 row in set (0.060 sec)   MariaDB [test]> select count (*) from alf_node_aspects; + ----------+ | count (*) | + ----------+ | 8192000 | + ----------+ 1 row in set (17.464 sec)   MariaDB [test]> select count (*) from alf_node_properties; + ----------+ | count (*) | + ----------+ | 216000 | + ----------+ 1 row in set (0.659 sec)   MariaDB [test]> select node.id as id from alf_node node left outer join alf_node_properties PROP_0 on (PROP_0.node_id = node.id) AND (43 = PROP_0.qname_id) where node.type_qname_id <> 149 AND node.store_id = 6 AND node.type_qname_id IN (35) AND node.id IN ( select PROP.node_id from alf_node_properties PROP where 919 = PROP.qname_id AND PROP.string_value = 'PKKM' AND node.id IN ( select aspect.node_id from alf_node_aspects aspect where aspect.qname_id IN (1146) AND node.id IN ( select PROP.node_id from alf_node_properties PROP where (1144 = PROP.qname_id) AND PROP.boolean_value = 1) order by PROP_0.string_value ASC )); Empty set (0.001 sec)   Explain Plan : ------------   MariaDB [test]> explain select node.id as id from alf_node node left outer join alf_node_properties PROP_0 on (PROP_0.node_id = node.id) AND (43 = PROP_0.qname_id) where node.type_qname_id <> 149 AND node.store_id = 6 AND node.type_qname_id IN (35) AND node.id IN ( select PROP.node_id from alf_node_properties PROP where 919 = PROP.qname_id AND PROP.string_value = 'PKKM' AND node.id IN ( select aspect.node_id from alf_node_aspects aspect where aspect.qname_id IN (1146) AND node.id IN ( select PROP.node_id from alf_node_properties PROP where (1144 = PROP.qname_id) AND PROP.boolean_value = 1) order by PROP_0.string_value ASC ))\G *************************** 1. row *************************** id: 1 select_type: PRIMARY table : aspect type: ref possible_keys: fk_alf_nasp_n,fk_alf_nasp_qn key : fk_alf_nasp_qn key_len: 8 ref: const rows : 1 Extra: Start temporary *************************** 2. row *************************** id: 1 select_type: PRIMARY table : node type: eq_ref possible_keys: PRIMARY ,fk_alf_node_store,idx_alf_node_mdq key : PRIMARY key_len: 8 ref: test.aspect.node_id rows : 1 Extra: Using where *************************** 3. row *************************** id: 1 select_type: PRIMARY table : PROP type: ref possible_keys: fk_alf_nprop_n,fk_alf_nprop_qn,idx_alf_nprop_s,idx_alf_nprop_l,idx_alf_nprop_b,idx_alf_nprop_f,idx_alf_nprop_d key : idx_alf_nprop_s key_len: 137 ref: const,const rows : 1 Extra: Using where *************************** 4. row *************************** id: 1 select_type: PRIMARY table : PROP type: ref possible_keys: fk_alf_nprop_n,fk_alf_nprop_qn,idx_alf_nprop_s,idx_alf_nprop_l,idx_alf_nprop_b,idx_alf_nprop_f,idx_alf_nprop_d key : fk_alf_nprop_qn key_len: 8 ref: const rows : 1 Extra: Using where *************************** 5. row *************************** id: 1 select_type: PRIMARY table : PROP_0 type: ref possible_keys: fk_alf_nprop_n,fk_alf_nprop_qn,idx_alf_nprop_s,idx_alf_nprop_l,idx_alf_nprop_b,idx_alf_nprop_f,idx_alf_nprop_d key : fk_alf_nprop_n key_len: 8 ref: test.aspect.node_id rows : 252 Extra: Using where ; End temporary 5 rows in set (0.001 sec)

Ramesh Sivaraman added a comment - 2021-12-07 04:10 Roel Could not reproduce the issue using provided dummy data. node1:root@localhost> select count (1) from alf_node_properties; + -----------+ | count (1) | + -----------+ | 206600536 | + -----------+ 1 row in set (13 min 30.436 sec)   node1:root@localhost> node1:root@localhost> select count (1) from alf_node; + -----------+ | count (1) | + -----------+ | 105317344 | + -----------+ 1 row in set (4 min 31.001 sec)   node1:root@localhost> select count (1) from alf_node_aspects; + -----------+ | count (1) | + -----------+ | 180000451 | + -----------+ 1 row in set (7 min 32.753 sec)   node1:root@localhost> node1:root@localhost> select node.id as id from alf_node node left outer join alf_node_properties PROP_0 on (PROP_0.node_id = node.id) AND (43 = PROP_0.qname_id) where node.type_qname_id <> 149 AND node.store_id = 6 AND node.type_qname_id IN (35) AND node.id IN ( select PROP.node_id from alf_node_properties PROP where 919 = PROP.qname_id AND PROP.string_value = 'PKKM' AND node.id IN ( select aspect.node_id from alf_node_aspects aspect where aspect.qname_id IN (1146) AND node.id IN ( select PROP.node_id from alf_node_properties PROP where (1144 = PROP.qname_id) AND PROP.boolean_value = 1) order by PROP_0.string_value ASC )); + ----+ | id | + ----+ | 32 | + ----+ 1 row in set (0.002 sec)   node1:root@localhost>

Michael Widenius added a comment - 2022-01-10 12:03 - edited I have examined the stack trace in detail, but unfortunately this is an optimized build and some of the vital information is not available. The crash is in aria write_block_record() when copying fixed record length columns to the record page. It is not clear why the buffer is overrun. As this is very old and stable code it is unclear how things could go wrong here. A non optimized build would be more helpful as in this case we get more information in gdb traces that could show the issue. In this particular case it would be very likely that a full backtrace of an unoptimized build could show in which structure the problem is. I am not sure that a ASAN/UBSAN build will help as it is not clear if this is a logical error in record length counting or if it stray write into another memory structure that causes the fault. It is very likely it will fail in exactly the same point without any additional information. One way to find out what is going on is to give me remote access to the computer with gdb, the core and server source. I am willing to log in to the customer site and do the debugging there to ensure we don't copy any sensitive data. This would enable me to find out which internal structure is wrong and what could have caused it. It would also help to get the mysqld.err file attached to the is ticket (or at least all information related to this failure)

Michael Widenius added a comment - 2022-01-10 12:19 About optimized builds. Note that the customer ONLY needs a copy of the mariadbd executable that he can use to temporarily replace the failing one. There is no need to do a full rpm for him. In theory someone could even log into the customer machine and compile it there. This would be the fastest way to get a quick turn around for finding the problem (as there may be needed several compile + fix + test cycles needed to find this bug...)