[MDEV-12474] Rocksdb - failing tests Created: 2017-04-07  Updated: 2023-12-20  Resolved: 2023-12-20

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - RocksDB, Tests
Affects Version/s: 10.2
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Vladislav Vaintroub Assignee: Sergei Petrunia
Resolution: Won't Fix Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-12469 FTBFS, compile time error with GCC7 Closed

 Description   

These tests fail on buildbot regularly :
Debug Win64:

Optmized Win64 :

Xenial fulltest:

Developers reported that validate_datadic and autoinc_vars_thread also occasionally fail on Linux, but this is not confirmed by buildbot so far



 Comments   
Comment by Daniel Black [ 2017-04-28 ]

I notice a few test failures are due to numeric precision that cannot be handled with regexes. https://github.com/MariaDB/server/pull/303 contains mysqltest enhancements to perform rounding that could be used for MyRocks

Comment by Elena Stepanova [ 2017-05-09 ]

Added the "Xenial fulltest" batch, except for the sys_vars tests which doesn't seem to be failing at the moment.
https://github.com/MariaDB/server/commit/001e54af70e9180e15ebfe8a95f8180f3983ba92

Comment by Elena Stepanova [ 2017-07-09 ]

https://internal.askmonty.org/buildbot/builders/kvm-deb-trusty-ppc64le/builds/1702/steps/mtr/logs/stdio

rocksdb_sys_vars.rocksdb_flush_memtable_on_analyze_basic w1 [ fail ]
        Test ended at 2017-07-09 19:27:11
 
CURRENT_TEST: rocksdb_sys_vars.rocksdb_flush_memtable_on_analyze_basic
--- /usr/share/mysql/mysql-test/plugin/rocksdb/rocksdb_sys_vars/r/rocksdb_flush_memtable_on_analyze_basic.result	2017-07-09 17:45:59.000000000 +0000
+++ /run/shm/var/1/log/rocksdb_flush_memtable_on_analyze_basic.reject	2017-07-09 19:27:11.835978322 +0000
@@ -48,7 +48,7 @@
 3	3
 SHOW TABLE STATUS LIKE 't1';
 Name	Engine	Version	Row_format	Rows	Avg_row_length	Data_length	Max_data_length	Index_length	Data_free	Auto_increment	Create_time	Update_time	Check_time	Collation	Checksum	Create_options	Comment
-t1	ROCKSDB	10	Fixed	#	#	69	0	0	0	4	NULL	NULL	NULL	latin1_swedish_ci	NULL		
+t1	ROCKSDB	10	Fixed	#	#	54	0	0	0	4	NULL	NULL	NULL	latin1_swedish_ci	NULL		
 ANALYZE TABLE t1;
 Table	Op	Msg_type	Msg_text
 test.t1	analyze	status	OK
 
mysqltest: Result content mismatch

Comment by Sergei Petrunia [ 2017-10-04 ]

Looking at 10.2 build as of revision 6ca35c14286d7649ff3938fd54fcf9c9bee6e136,
I see no failing MyRocks tests.

Some tests do not fail because they are disabled (and there are MDEVs for these). Closing.

Comment by Sergei Golubchik [ 2017-10-04 ]

Reopened. They don't fail any more because they were disabled (because they were failing). This is the complete list from storage/rocksdb/mysql-test/rocksdb/t/disabled.def:

# MDEV-12474 Regularly failing tests on Buildbot
autoinc_vars_thread : MDEV-12474 Regularly fails on buildbot
unique_check : MDEV-12474 Regularly fails on buildbot
bloomfilter : MDEV-12474 Regularly fails on buildbot
compact_deletes: MDEV-12663 : rocksdb.compact_deletes times out and causes other tests to fail
col_opt_not_null : MDEV-12474 - Fails in fulltest
col_opt_null :   : MDEV-12474 - Fails in fulltest
col_opt_unsigned : MDEV-12474 - Fails in fulltest
col_opt_zerofill : MDEV-12474 - Fails in fulltest
type_float       : MDEV-12474 - Fails in fulltest

Supposedly, some of them fail because of missing features — they will stay disabled, just shouldn't mention MDEV-12474 anymore. Those that are bugs, should be fixed.

Comment by Sergei Petrunia [ 2017-10-26 ]

Pushed a fix for these tests:

-col_opt_not_null : MDEV-12474 - Fails in fulltest
-col_opt_null :   : MDEV-12474 - Fails in fulltest
-col_opt_unsigned : MDEV-12474 - Fails in fulltest
-col_opt_zerofill : MDEV-12474 - Fails in fulltest
-type_float       : MDEV-12474 - Fails in fulltest

Comment by Alice Sherepa [ 2017-10-27 ]

http://buildbot.askmonty.org/buildbot/builders/kvm-fulltest/builds/10748/steps/test_3/logs/stdio

rocksdb.col_opt_zerofill                 w4 [ fail ]
        Test ended at 2017-10-26 15:34:28
 
CURRENT_TEST: rocksdb.col_opt_zerofill
mysqltest: In included file "/mnt/buildbot/build/mariadb-10.2.10/storage/rocksdb/mysql-test/rocksdb/t/type_int.inc": 
included from /mnt/buildbot/build/mariadb-10.2.10/storage/rocksdb/mysql-test/rocksdb/t/col_opt_zerofill.test at line 50:
At line 41: mysql_fetch didn't end with MYSQL_NO_DATA from statement: error: 101
 
The result from queries just before the failure was:
< snip >
t0	tinyint(3) unsigned zerofill	YES		NULL	
t1	tinyint(1) unsigned zerofill	YES		NULL	
t20	tinyint(20) unsigned zerofill	YES		NULL	
s	smallint(5) unsigned zerofill	YES		NULL	
s0	smallint(5) unsigned zerofill	YES		NULL	
s1	smallint(1) unsigned zerofill	YES		NULL	
s20	smallint(20) unsigned zerofill	YES		NULL	
m	mediumint(8) unsigned zerofill	YES		NULL	
m0	mediumint(8) unsigned zerofill	YES		NULL	
m1	mediumint(1) unsigned zerofill	YES		NULL	
m20	mediumint(20) unsigned zerofill	YES		NULL	
b	bigint(20) unsigned zerofill	YES		NULL	
b0	bigint(20) unsigned zerofill	YES		NULL	
b1	bigint(1) unsigned zerofill	YES		NULL	
b20	bigint(20) unsigned zerofill	YES		NULL	
pk	int(11)	NO	PRI	NULL	auto_increment
INSERT INTO t1 (i,i0,i1,i20,t,t0,t1,t20,s,s0,s1,s20,m,m0,m1,m20,b,b0,b1,b20) VALUES (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20);
INSERT INTO t1 (i,i0,i1,i20,t,t0,t1,t20,s,s0,s1,s20,m,m0,m1,m20,b,b0,b1,b20) VALUES (0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0);
INSERT INTO t1 (i,i0,i1,i20,t,t0,t1,t20,s,s0,s1,s20,m,m0,m1,m20,b,b0,b1,b20) VALUES (2147483647,2147483647,2147483647,2147483647,127,127,127,127,32767,32767,32767,32767,8388607,8388607,8388607,8388607,9223372036854775807,9223372036854775807,9223372036854775807,9223372036854775807);
SELECT i,i0,i1,i20,t,t0,t1,t20,s,s0,s1,s20,m,m0,m1,m20,b,b0,b1,b20 FROM t1;
 
More results from queries before failure can be found in /mnt/buildbot/build/mariadb-10.2.10/mysql-test/var/4/log/col_opt_zerofill.log

Comment by Sergei Petrunia [ 2017-10-27 ]

alice, the above is now filed as MDEV-14165. (It's not a MyRocks problem btw) I have disabled the test.

Comment by Sergei Petrunia [ 2017-10-27 ]

rocksdb.rocksdb still fails like so:
http://buildbot.askmonty.org/buildbot/builders/kvm-fulltest/builds/10749/steps/test_3/logs/stdio

rocksdb.rocksdb                          w2 [ fail ]
        Test ended at 2017-10-26 15:25:53
 
CURRENT_TEST: rocksdb.rocksdb
mysqltest: At line 1117: query 'reap' succeeded - should have failed with errno 1317...
 
The result from queries just before the failure was:
< snip >
pk
affected rows: 0
DROP TABLE t1,t2;
#
# MDEV-4374: RocksDB: Valgrind warnings 'Use of uninitialised value' on 
#   inserting into a varchar column
#
CREATE TABLE t1 (pk INT PRIMARY KEY, a VARCHAR(32)) ENGINE=RocksDB;

  • No idea about the cause of this
  • It's not reproducible anywhere I tried
Comment by Alice Sherepa [ 2017-11-24 ]

http://buildbot.askmonty.org/buildbot/builders/winx64-packages/builds/5841/steps/test/logs/stdio

rocksdb.bloomfilter                      w4 [ fail ]
        Test ended at 2017-11-24 02:18:32
 
CURRENT_TEST: rocksdb.bloomfilter
--- D:/winx64-packages/build/src/storage/rocksdb/mysql-test/rocksdb/r/bloomfilter.result	2017-11-24 00:49:21.000000000 +0000
+++ D:\winx64-packages\build\src\storage\rocksdb\mysql-test\rocksdb\r\bloomfilter.reject	2017-11-24 02:18:31.707460300 +0000
@@ -84,63 +84,63 @@
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index(id2_id1)  where id2=24 and id1=12;
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index(id2_id1)  where id2=88 and id1=44;
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index(id2_id1)  where id2=100 and id1=50;
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index(id2_id1)  where id2=428 and id1=214;
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id2_id4_id5) where id2=1 and id4=1 and id5=1;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id2_id4_id5) where id2=23 and id4=115 and id5=115;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id2_id4_id5) where id2=500 and id4=2500 and id5=2500;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id2_id4_id5) where id2=601 and id4=3005 and id5=3005;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id2_id3) where id2=1;
 count(*)
@@ -203,77 +203,77 @@
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index (id2_id3_id1_id4) where id2=36 and id3='36' and id1=18 order by id4;
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index (id2_id3_id1_id4) where id2=124 and id3='124' and id1=62 order by id4;
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index (id2_id3_id1_id4) where id2=888 and id3='888' and id1=444 order by id4;
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index (id2_id3_id1_id4) where id2=124 and id3='124';
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id2_id3) where id2=1 and id3='1' and id4=1;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id2_id3) where id2=12 and id3='12' and id4=60;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index (id2_id3) where id2=1 and id3='1';
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index (id2_id3) where id2=23 and id3='23';
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index (id3_id2) where id2=1 and id3='1';
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index (id3_id2) where id2=23 and id3='23';
 count(*)
 5
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index (PRIMARY) where id1=1;
 count(*)
@@ -329,42 +329,42 @@
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id2) where id2=23 and id4=115;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id2) where id2=500 and id4=2500;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id2) where id2=601 and id4=3005;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id3_id4) where id3='1' and id4=1;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2 force index (id3_id4) where id3='12' and id4=60;
 count(*)
 1
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t1 force index (id2) where id2=1;
 count(*)
@@ -449,7 +449,7 @@
 10000
 call bloom_end();
 checked
-true
+false
 call bloom_start();
 select count(*) from t2;
 count(*)
 
mysqltest: Result length mismatch

Comment by Sergei Petrunia [ 2018-01-04 ]

rocksdb.optimize_table now fails like so:

http://buildbot.askmonty.org/buildbot/builders/winx64-packages/builds/6376/steps/test/logs/stdio

2018-01-03 18:03:11 3412 [Note]     target_file_size_base=65536
180103 18:03:18 [ERROR] mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.
 
Server version: 10.2.12-MariaDB-log
key_buffer_size=1048576
read_buffer_size=131072
max_used_connections=1
max_threads=65537
thread_count=2
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4260 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x16e1054418
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
ha_rocksdb.dll!rocksdb::log::Writer::AddRecord()[log_writer.cc:44]
ha_rocksdb.dll!rocksdb::DBImpl::WriteToWAL()[db_impl_write.cc:705]
ha_rocksdb.dll!rocksdb::DBImpl::ConcurrentWriteToWAL()[db_impl_write.cc:805]
ha_rocksdb.dll!rocksdb::DBImpl::WriteImpl()[db_impl_write.cc:240]
ha_rocksdb.dll!rocksdb::DBImpl::Write()[db_impl_write.cc:49]
ha_rocksdb.dll!rocksdb::WriteCommittedTxn::CommitWithoutPrepareInternal()[pessimistic_transaction.cc:306]
ha_rocksdb.dll!rocksdb::PessimisticTransaction::Commit()[pessimistic_transaction.cc:264]
ha_rocksdb.dll!myrocks::Rdb_transaction_impl::commit_no_binlog()[ha_rocksdb.cc:2283]
ha_rocksdb.dll!myrocks::rocksdb_commit()[ha_rocksdb.cc:3157]
mysqld.exe!commit_one_phase_2()[handler.cc:1571]
mysqld.exe!ha_commit_one_phase()[handler.cc:1554]
mysqld.exe!ha_commit_trans()[handler.cc:1419]
mysqld.exe!trans_commit_stmt()[transaction.cc:511]
mysqld.exe!mysql_execute_command()[sql_parse.cc:6326]
mysqld.exe!mysql_parse()[sql_parse.cc:7982]
mysqld.exe!dispatch_command()[sql_parse.cc:1836]
mysqld.exe!do_command()[sql_parse.cc:1382]
mysqld.exe!threadpool_process_request()[threadpool_common.cc:366]
mysqld.exe!tp_callback()[threadpool_common.cc:192]
ntdll.dll!RtlFreeUnicodeString()
ntdll.dll!RtlFreeUnicodeString()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x16e1062fa0): INSERT INTO t3 VALUES(2443, 2443, REPEAT('x', 150))
Connection ID (thread ID): 4
Status: NOT_KILLED

Comment by Anel Husakovic [ 2020-06-22 ]

PR #1598 is addressing the patch for the failing test rocksdb.concurrent_alter on freebsd.

Generated at Thu Feb 08 07:58:00 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.