[MDEV-15245] Assertion `false' failed in myrocks::ha_rocksdb::position Created: 2018-02-08  Updated: 2018-03-11  Resolved: 2018-03-11

Status: Closed
Project: MariaDB Server
Component/s: Partitioning, Storage Engine - RocksDB
Affects Version/s: 10.3
Fix Version/s: 10.2.14

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: affects-tests


 Description   

--source include/have_partition.inc
 
INSTALL SONAME 'ha_rocksdb';
 
CREATE TABLE t1 (a INT) ENGINE=RocksDB;
INSERT INTO t1 VALUES (1),(2);
 
# partitoning
CREATE TABLE t2 (b INT) ENGINE=RocksDB PARTITION BY RANGE(b) (PARTITION p0 VALUES LESS THAN (1), PARTITION p1 VALUES LESS THAN MAXVALUE);
INSERT IGNORE INTO t2 VALUES (NULL),(0);
 
CREATE ALGORITHM = MERGE VIEW v1 AS SELECT t2.* FROM t1, t2;
UPDATE v1 SET b = 5;

10.3 029ab11cc8

mysqld: /data/src/10.3/storage/rocksdb/ha_rocksdb.cc:9709: virtual void myrocks::ha_rocksdb::position(const uchar*): Assertion `false' failed.
180208  3:09:47 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fedd5ba2ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x00007fedcae4beaa in myrocks::ha_rocksdb::position (this=0x7fedb4382f68, record=0x7fedb4382300 "\375") at /data/src/10.3/storage/rocksdb/ha_rocksdb.cc:9709
#9  0x000055b33eca58f6 in ha_partition::position (this=0x7fedb4381a48, record=0x7fedb4382300 "\375") at /data/src/10.3/sql/ha_partition.cc:5109
#10 0x000055b33e29c24b in sub_select (join=0x7fedb40194f8, join_tab=0x7fedb4393028, end_of_records=false) at /data/src/10.3/sql/sql_select.cc:19339
#11 0x000055b33e29c7bd in evaluate_join_record (join=0x7fedb40194f8, join_tab=0x7fedb4392c78, error=0) at /data/src/10.3/sql/sql_select.cc:19522
#12 0x000055b33e29c0d4 in sub_select (join=0x7fedb40194f8, join_tab=0x7fedb4392c78, end_of_records=false) at /data/src/10.3/sql/sql_select.cc:19302
#13 0x000055b33e29b63d in do_select (join=0x7fedb40194f8, procedure=0x0) at /data/src/10.3/sql/sql_select.cc:18842
#14 0x000055b33e274700 in JOIN::exec_inner (this=0x7fedb40194f8) at /data/src/10.3/sql/sql_select.cc:4061
#15 0x000055b33e27396c in JOIN::exec (this=0x7fedb40194f8) at /data/src/10.3/sql/sql_select.cc:3844
#16 0x000055b33e274de5 in mysql_select (thd=0x7fedb4000b00, tables=0x7fedb4014d40, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=1342177408, result=0x7fedb4019420, unit=0x7fedb4004890, select_lex=0x7fedb4004ff8) at /data/src/10.3/sql/sql_select.cc:4260
#17 0x000055b33e32280c in mysql_multi_update (thd=0x7fedb4000b00, table_list=0x7fedb4014d40, fields=0x7fedb4005120, values=0x7fedb4005608, conds=0x0, options=0, handle_duplicates=DUP_ERROR, ignore=false, unit=0x7fedb4004890, select_lex=0x7fedb4004ff8, result=0x7fedd06117a0) at /data/src/10.3/sql/sql_update.cc:1736
#18 0x000055b33e22a90f in mysql_execute_command (thd=0x7fedb4000b00) at /data/src/10.3/sql/sql_parse.cc:4626
#19 0x000055b33e235378 in mysql_parse (thd=0x7fedb4000b00, rawbuf=0x7fedb4014c68 "UPDATE v1 SET b = 5", length=19, parser_state=0x7fedd06125e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7977
#20 0x000055b33e222bbf in dispatch_command (command=COM_QUERY, thd=0x7fedb4000b00, packet=0x7fedb400b171 "UPDATE v1 SET b = 5", packet_length=19, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1825
#21 0x000055b33e2215fe in do_command (thd=0x7fedb4000b00) at /data/src/10.3/sql/sql_parse.cc:1370
#22 0x000055b33e388fa4 in do_handle_one_connection (connect=0x55b341d80290) at /data/src/10.3/sql/sql_connect.cc:1402
#23 0x000055b33e388d31 in handle_one_connection (arg=0x55b341d80290) at /data/src/10.3/sql/sql_connect.cc:1308
#24 0x000055b33e827929 in pfs_spawn_thread (arg=0x55b341e43b90) at /data/src/10.3/storage/perfschema/pfs.cc:1862
#25 0x00007fedd7879494 in start_thread (arg=0x7fedd0613700) at pthread_create.c:333
#26 0x00007fedd5c5f93f in clone () from /lib/x86_64-linux-gnu/libc.so.6



 Comments   
Comment by Sergei Petrunia [ 2018-03-09 ]

Analysis:
the crash happens because SQL layer calls ha_rocksdb::position() without first
having read a row from ha_rocksdb object.

Partitioning is needed because we need to get into the loop in subselect.
Without partitioning, we can only

  • find no rows at all and never enter the loop
  • find some row, in which case ha_rocksdb::position() will then succeed.

With partitioning, it is possible to have both

  • find row in partition p0 so we enter the loop in sub_select
  • then, find nothing in the second partition, so attempt to call
    position() for it will cause an assert
Comment by Sergei Petrunia [ 2018-03-11 ]

Upstream is not affected because they don't attempt the bad ::position call.

Generated at Thu Feb 08 08:19:47 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.