[MDEV-8510] main.status test fails sporadically in buildbot Created: 2015-07-21  Updated: 2023-11-29  Resolved: 2023-11-29

Status: Closed
Project: MariaDB Server
Component/s: Tests
Affects Version/s: 10.1
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None

Issue Links:
Blocks
blocks MDEV-7069 Fix buildbot failures in main server ... Stalled
Relates
relates to MDEV-13255 main.status failed in buildbot Closed

 Description   

http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-quantal-amd64/builds/1641/steps/test/logs/stdio

main.status                              w2 [ fail ]
 
        Test ended at 2015-07-20 18:41:05
 
 
 
CURRENT_TEST: main.status
 
--- /usr/local/mariadb-10.0.20-linux-x86_64/mysql-test/r/status.result	2015-07-20 14:41:12.000000000 +0300
 
+++ /usr/local/mariadb-10.0.20-linux-x86_64/mysql-test/r/status.reject	2015-07-20 18:41:05.098326356 +0300
 
@@ -182,7 +182,7 @@
 
 Variable_name	Value
 
 Com_show_status	8
 
 rnd_diff	tmp_table_diff
 
-28	8
 
+26	8
 
 flush status;
 
 show status like 'Com%function';
 
 Variable_name	Value
 
 
 
mysqltest: Result content mismatch

Fails from time to time on different builders. I could not reproduce it even by running the test 1000 times. Sequence of tests should not be important, since the server gets restarted before the test.

 Comments   
Comment by Elena Stepanova [ 2016-06-15 ]

The problem has not happened in buildbot on 10.0 since July 20, 2015 and on 10.1 since August 2015. Before that, it was happening ~2-4 times a month, so I think we can safely assume it disappeared from the trees. It's possible it was somehow related to (and fixed with) MDEV-8301, the timing fits.

Comment by Elena Stepanova [ 2016-08-27 ]

A new flavor of failure occurred in buildbot at least once:
http://buildbot.askmonty.org/buildbot/builders/winx64-debug/builds/237/steps/test/logs/stdio

main.status                              w4 [ fail ]
 
        Test ended at 2016-06-03 12:22:51
 
 
 
CURRENT_TEST: main.status
 
--- D:/winx64-debug/build/src/mysql-test/r/status.result	2016-06-03 11:47:05.223039600 +0000
 
+++ D:\winx64-debug\build\src\mysql-test\r\status.reject	2016-06-03 12:22:51.397420800 +0000
 
@@ -242,9 +242,9 @@
 
 CALL p1();
 
 1
 
 1
 
-SELECT 9;
 
-9
 
-9
 
+SELECT 10;
 
+10
 
+10
 
 DROP PROCEDURE p1;
 
 DROP FUNCTION f1;
 
 flush status;
 
 
 
mysqltest: Result length mismatch

Comment by Laurynas Biveinis [ 2017-04-24 ]

For this latter failure I have added log dump in case of failure and it appears to be caused by earlier testcase disconnects completing asynchronously during this logging-enabled window. The testcase tries to wait for some of the disconnects to complete by waiting for the threads to disappear from processlist, but 1) this is not universal for all connections; 2) the threads disappear from processlist early in the disconnect process.

I have changed the testcase to use wait_until_count_sessions.inc (Threads_connected decrement happens very late in the disconnect): https://github.com/percona/percona-server/pull/1679. The diff contains semi-related changes of reverting that previously added dump

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