[MDEV-26540] Spider: Assertion `inited==RND' failed in handler::ha_rnd_end on DELETE Created: 2021-09-05  Updated: 2023-12-08

Status: Confirmed
Project: MariaDB Server
Component/s: Data Manipulation - Delete, Partitioning, Storage Engine - Spider
Affects Version/s: 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11
Fix Version/s: 10.4, 10.5, 10.6

Type: Bug Priority: Major
Reporter: Roel Van de Paar Assignee: Alexey Botchkov
Resolution: Unresolved Votes: 0
Labels: not-10.2, not-11.0, regression

Issue Links:
Relates
relates to MDEV-32097 Assertion `inited==RND' failed in han... Confirmed
relates to MDEV-26539 SIGSEGV in spider_check_and_set_trx_i... Closed

 Description    

INSTALL PLUGIN spider SONAME 'ha_spider.so';
 
CREATE TABLE t (c INT) PARTITION BY LIST COLUMNS (c) (PARTITION p DEFAULT ENGINE=SPIDER);
 
INSERT INTO t VALUES (1);
 
DELETE FROM t;

Leads to:

10.7.0 1bc82aaf0a7746c0921a94034aff2d51f0d75cd0 (Debug)

 
mysqld: /test/10.7_dbg/sql/handler.h:3542: int handler::ha_rnd_end(): Assertion `inited==RND' failed.

10.7.0 1bc82aaf0a7746c0921a94034aff2d51f0d75cd0 (Debug)

 
Core was generated by `/test/MD040921-mariadb-10.7.0-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
 
Program terminated with signal SIGABRT, Aborted.
 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 
[Current thread is 1 (Thread 0x14d350062700 (LWP 3952612))]
 
(gdb) bt
 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 
#1  0x000014d35281f859 in __GI_abort () at abort.c:79
 
#2  0x000014d35281f729 in __assert_fail_base (fmt=0x14d3529b5588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55fd4f99a8be "inited==RND", file=0x55fd4f765b05 "/test/10.7_dbg/sql/handler.h", line=3542, function=<optimized out>) at assert.c:92
 
#3  0x000014d352830f36 in __GI___assert_fail (assertion=assertion@entry=0x55fd4f99a8be "inited==RND", file=file@entry=0x55fd4f765b05 "/test/10.7_dbg/sql/handler.h", line=line@entry=3542, function=function@entry=0x55fd4f765b2d "int handler::ha_rnd_end()") at assert.c:101
 
#4  0x000055fd4f0bfeda in handler::ha_rnd_end (this=0x14d30c07c5a0) at /test/10.7_dbg/sql/handler.h:3542
 
#5  ha_partition::direct_delete_rows (this=0x14d30c02fe70, delete_rows_result=<optimized out>) at /test/10.7_dbg/sql/ha_partition.cc:11933
 
#6  0x000055fd4ee0be2b in handler::ha_direct_delete_rows (this=0x14d30c02fe70, delete_rows=delete_rows@entry=0x14d350060578) at /test/10.7_dbg/sql/handler.cc:7729
 
#7  0x000055fd4ea9ef82 in mysql_delete (thd=thd@entry=0x14d30c000db8, table_list=0x14d30c013d40, conds=<optimized out>, order_list=order_list@entry=0x14d30c005c00, limit=18446744073709551615, options=<optimized out>, result=<optimized out>) at /test/10.7_dbg/sql/sql_delete.cc:646
 
#8  0x000055fd4eb01c13 in mysql_execute_command (thd=thd@entry=0x14d30c000db8, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.7_dbg/sql/sql_limit.h:83
 
#9  0x000055fd4eaebccb in mysql_parse (thd=thd@entry=0x14d30c000db8, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14d350061400) at /test/10.7_dbg/sql/sql_parse.cc:8036
 
#10 0x000055fd4eafa8d0 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14d30c000db8, packet=packet@entry=0x14d30c00b739 "DELETE FROM t", packet_length=packet_length@entry=13, blocking=blocking@entry=true) at /test/10.7_dbg/sql/sql_class.h:1358
 
#11 0x000055fd4eafdcd6 in do_command (thd=0x14d30c000db8, blocking=blocking@entry=true) at /test/10.7_dbg/sql/sql_parse.cc:1404
 
#12 0x000055fd4ec740c8 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55fd5160a3e8, put_in_cache=put_in_cache@entry=true) at /test/10.7_dbg/sql/sql_connect.cc:1418
 
#13 0x000055fd4ec746cd in handle_one_connection (arg=arg@entry=0x55fd5160a3e8) at /test/10.7_dbg/sql/sql_connect.cc:1312
 
#14 0x000055fd4f0ddade in pfs_spawn_thread (arg=0x55fd515092b8) at /test/10.7_dbg/storage/perfschema/pfs.cc:2201
 
#15 0x000014d352d2e609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#16 0x000014d35291c293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.4.22 (dbg), 10.5.13 (dbg), 10.6.5 (dbg), 10.7.0 (dbg)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.2.41 (dbg), 10.2.41 (opt), 10.3.32 (dbg), 10.3.32 (opt), 10.4.22 (opt), 10.5.13 (opt), 10.6.5 (opt), 10.7.0 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.51 (dbg), 5.6.51 (opt), 5.7.35 (dbg), 5.7.35 (opt), 8.0.26 (dbg), 8.0.26 (opt)

 Comments   
Comment by Roel Van de Paar [ 2021-09-05 ]

Note same assert is being triggered in MDEV-21415 and others linked from it.

Comment by Roel Van de Paar [ 2021-09-05 ]

Additional testcase

INSTALL PLUGIN spider SONAME 'ha_spider.so';
 
CREATE TABLE t (c INT) PARTITION BY LIST COLUMNS (c) (PARTITION p DEFAULT ENGINE=SPIDER);
 
DELETE FROM t;
 
DELETE FROM t;

Comment by Nayuta Yanagisawa (Inactive) [ 2021-09-21 ]

The bug is reproducible also on 10.3 (b112c9d) but not on 10.2.

Comment by Nayuta Yanagisawa (Inactive) [ 2021-09-21 ]

This reproduce at least on mariadb-10.3.15 or later.

Comment by Nayuta Yanagisawa (Inactive) [ 2021-09-27 ]

The bug is at least reproducible on mariadb-10.3.4 or later.

Comment by Nayuta Yanagisawa (Inactive) [ 2021-09-27 ]

The bug is reproducible on 10.3.3, but not on 10.3.2.

Comment by Nayuta Yanagisawa (Inactive) [ 2021-09-27 ]

MTR test case:

--disable_query_log
 
--disable_result_log
 
--source test_init.inc
 
--enable_result_log
 
--enable_query_log
 
 
 
--connection master_1
 
 
 
CREATE TABLE t (c INT) PARTITION BY LIST COLUMNS (c) (PARTITION p DEFAULT ENGINE=SPIDER);
 
--error 1429
 
INSERT INTO t VALUES (1);
 
--error 1429
 
DELETE FROM t;
 
 
 
--disable_query_log
 
--disable_result_log
 
--source test_deinit.inc
 
--enable_result_log
 
--enable_query_log

The result of git-bisect:

e53ef202bd7706b88760472472af5ae878065f4f is the first bad commit
 
commit e53ef202bd7706b88760472472af5ae878065f4f
 
Author: Kentoku SHIBA <kentokushiba@gmail.com>
 
Date:   Thu Nov 16 11:11:52 2017 +0200
 
 
 
    Adding direct update/delete to the server and to the partition engine.
 
 
 
    Add support for direct update and direct delete requests for spider.
 
    A direct update/delete request handles all qualified rows in a single
 
    operation rather than one row at a time.
 
 
 
    Contains Spiral patches:
 
    006_mariadb-10.2.0.direct_update_rows.diff      MDEV-7704
 
    008_mariadb-10.2.0.partition_direct_update.diff MDEV-7706
 
    010_mariadb-10.2.0.direct_update_rows2.diff     MDEV-7708
 
    011_mariadb-10.2.0.aggregate.diff               MDEV-7709
 
    027_mariadb-10.2.0.force_bulk_update.diff       MDEV-7724
 
    061_mariadb-10.2.0.mariadb-10.1.8.diff          MDEV-12870
 
 
 
    - The differences compared to the original patches:
 
      - Most of the parameters of the new functions are unnecessary.  The
 
        unnecessary parameters have been removed.
 
      - Changed bit positions for new handler flags upon consideration of
 
        handler flags not needed by other Spiral patches and handler flags
 
        merged from MySQL.
 
      - Added info_push() (Was originally part of bulk access patch)
 
      - Didn't include code related to handler socket
 
      - Added HA_CAN_DIRECT_UPDATE_AND_DELETE
 
 
 
    Original author: Kentoku SHIBA
 
    First reviewer:  Jacob Mathew
 
    Second reviewer: Michael Widenius
 
 
 
 sql/ha_partition.cc                                | 585 +++++++++++++++++++++
 
 sql/ha_partition.h                                 |  17 +
 
 sql/handler.cc                                     |  55 +-
 
 sql/handler.h                                      | 121 ++++-
 
 sql/opt_sum.cc                                     |   3 +
 
 sql/sql_delete.cc                                  |  75 ++-
 
 sql/sql_update.cc                                  |  96 +++-
 
 sql/table.cc                                       |  53 ++
 
 sql/table.h                                        |   2 +
 
 storage/spider/ha_spider.cc                        |  29 +-
 
 storage/spider/ha_spider.h                         |  62 ++-
 
 .../mysql-test/spider/bg/r/direct_update.result    |   8 +
 
 .../spider/bg/r/direct_update_part.result          |   8 +
 
 .../mysql-test/spider/bg/r/spider_fixes.result     |   1 +
 
 .../spider/handler/r/direct_update.result          |   8 +
 
 .../spider/handler/r/direct_update_part.result     |   8 +
 
 .../spider/handler/r/spider_fixes.result           |   1 +
 
 .../mysql-test/spider/r/direct_update.result       |   8 +
 
 .../mysql-test/spider/r/direct_update_part.result  |   8 +
 
 .../spider/mysql-test/spider/r/spider_fixes.result |   1 +
 
 storage/spider/spd_db_conn.cc                      |  22 +-
 
 storage/spider/spd_db_conn.h                       |  10 +-
 
 storage/spider/spd_environ.h                       |   3 +-
 
 23 files changed, 1116 insertions(+), 68 deletions(-)

Comment by Nayuta Yanagisawa (Inactive) [ 2021-09-27 ]

I've checked the diff of e53ef20. ha_partition::direct_delete_rows() has been added by the above commit and the failing assertion is in the server code. So, I now think this is not a Spider problem but a server problem.

Comment by Alexey Botchkov [ 2021-10-05 ]

https://github.com/MariaDB/server/commit/ecd1aaa60d1af231fffa4b0788b2a2d073a66cc0

Comment by Roel Van de Paar [ 2023-03-03 ]

Interestingly, this bug does not exist in 11.0.

holyfoot Is the patch ready for review? Assigned to ycp for review, but please revert if not.

Comment by Yuchen Pei [ 2023-03-22 ]

roel OK
holyfoot Can you rebase on the current 10.3? Thanks.

Comment by Yuchen Pei [ 2023-10-11 ]

The similar-looking test case from ramesh in MDEV-27902 causes
the same assertion failure at the DELETE statement despite the
fix below, so I "move" the case here.

2374b33bf2f bb-10.5-mdev-27902 MDEV-27902 Spider check trx and get conn in rnd_next()

Further, it does not cause a problem in the 11.0 version of the same
fix, which agrees with roel's comment above:

458c0b80fbd upstream/bb-11.0-mdev-27902 MDEV-27902 Spider check trx and get conn in rnd_next()
 

# Note: add appropriate preamble and postamble before testing.
 
CREATE TABLE t (c INT,c2 INT)  engine=Spider PARTITION BY HASH (c) PARTITIONS 4  ;
 
--error ER_CONNECT_TO_FOREIGN_DATA_SOURCE
 
UPDATE t SET a=((1));
 
LOCK TABLES t WRITE CONCURRENT;
 
--error 13
 
LOAD DATA INFILE 'unkownfile.txt' IGNORE INTO TABLE t IGNORE 4 LINES;
 
--error ER_CONNECT_TO_FOREIGN_DATA_SOURCE
 
DELETE FROM t;
 
UNLOCK TABLES;

Comment by Yuchen Pei [ 2023-12-07 ]

The MDEV-27902 case with the same issue (in 10.4-10.11) seems to be
fixed (at least in 10.11 3e90efe4c98f00e96e081bd1c571ea1e25b06258) if
we apply the following diff which is like the following patch which is
in 11.0+:

modified   sql/sql_delete.cc
 
@@ -534,7 +534,9 @@ bool mysql_delete(THD *thd, TABLE_LIST *table_list, COND *conds,
 
   select=make_select(table, 0, 0, conds, (SORT_INFO*) 0, 0, &error);
 
   if (unlikely(error))
 
     DBUG_RETURN(TRUE);
 
-  if ((select && select->check_quick(thd, safe_update, limit)) || !limit)
 
+  if (unlikely((select && select->check_quick(thd, safe_update, limit)) ||
 
+               table->stat_records() == 0 ||
 
+               !limit))
 
   {
 
     query_plan.set_impossible_where();
 
     if (thd->lex->describe || thd->lex->analyze_stmt)
 

9a4110aa5799d63faced5f986fab9035785a9310
 
MDEV-30256 Wrong result (missing rows) upon join with empty table
 
 
 
The problem was an assignment in test_quick_select() that flagged empty
 
tables with "Impossible where". This test was however wrong as it
 
didn't work correctly for left join.
 
 
 
Removed the test, but added checking of empty tables in DELETE and UPDATE
 
to get similar EXPLAIN as before.
 
 
 
The new tests is a bit more strict (better) than before as it catches all
 
cases of empty tables in single table DELETE/UPDATE.

Generated at Thu Feb 08 09:46:04 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.