The Basics

At its core, mariadb-test is very simple. The client program mariadb-test executes a test file and compares the produced output with the result &#xNAN;file. If the files match, the test is passed; otherwise the test has failed. This approach can be used to test any SQL statement, as well as other executables (with the exec command).

The complete process of testing is governed and monitored by the mariadb-test-run.pl driver script, or mtr for short (for convenience,mtr is created as a symbolic link to mariadb-test-run.pl). The mtr script is responsible for preparing the test environment, creating a list of all tests to run, running them, and producing the report at the end. It can run many tests in parallel, execute tests in an order which minimizes server restarts (as they are slow), run tests in a debugger or under valgrind or strace, and so on.

Test files are located in suites. A suite is a directory which contains test files, result files, and optional configuration files. The mtr looks for suites in the mariadb-test/suite directory, and in the mariadb-test subdirectories of plugins and storage engine directories. For example, the following are all valid suite paths:

mariadb-test/suite/rpl

mariadb-test/suite/handler

storage/example/mariadb-test/demo

plugin/auth_pam/mariadb-test/pam

In almost all cases, the suite directory name is the suite name. A notable historical exception is the main suite, which is located directly in themariadb-test directory.

Test files have a .test extension and can be placed directly in the suite directory (for example, mariadb-test/suite/handler/interface.test) or in thet subdirectory (e.g. mariadb-test/suite/rpl/t/rpl_alter.test ormariadb-test/t/grant.test). Similarly, result files have the .result extension and can be placed either in the suite directory or in the r subdirectory.

A test file can include other files (with the source command). These included files can have any name and may be placed anywhere, but customarily they have a .inc extension and are located either in the suite directory or in the inc or include subdirectories (for example,mariadb-test/suite/handler/init.inc ormariadb-test/include/start_slave.inc).

Other files which affect testing, while not being tests themselves, are:

• disabled.def

• suite.opt

• other *.opt files

• my.cnf

• other *.cnf files

• combinations

• other *.combinations files

• suite.pm

• *.sh files

• *.require files

• *.rdiff files

• valgrind.supp

See Auxiliary files for details on these.

Overlays

In addition to regular suite directories, mtr supports overlays. An overlay is a directory with the same name as an existing suite, but which is located in a storage engine or plugin directory. For example,storage/myisam/mariadb-test/rpl could be a myisam overlay of the rpl suite in mariadb-test/suite/rpl. Andplugin/daemon_example/mariadb-test/demo could be a daemon_example overlay of the demo suite in storage/example/mariadb-test/demo. As a special exception, an overlay of the main suite, should be called main, as instorage/pbxt/mariadb-test/main.

An overlay is like a second transparent layer in a graphics editor. It can obscure, extend, or modify the background image. Also, one may notice that an overlay is very close to a UnionFS, but implemented in perl inside mtr.

An overlay can replace almost any file in the overlaid suite, or add new files. For example, if some overlay of the main suite contains ainclude/have_innodb.inc file, then all tests that include it will see and use the overlaid version. Or, an overlay can create a t/create.opt file (even though the main suite does not have such a file), and create.test will be executed with the specified additional options.

But adding an overlay never affects how the original suite is executed. That is, mtr always executes the original suite as if no overlay was present. And then, additionally, it executes a combined "union" of the overlay and the original suite. When doing that, mtr takes care to avoid re-executing tests that are not changed in the overlay. For example, creating t/create.opt in the overlay of the main suite will only cause create.test to be executed in the overlay. But creating suite.opt affects all tests — and it will cause all tests to be re-executed with the new options.

Combinations

In certain cases it makes sense to run a specific test or a group of tests several times with different server settings. This can be done using so-called combinations. Combinations are groups of settings that are used alternatively. A combinations file defines these alternatives using my.cnf syntax, for example

[row]
binlog-format=row

[stmt]
binlog-format=statement

[mix]
binlog-format=mixed

And all tests where this combinations file applies will be run three times: once for the combination called "row", and --binlog-format=row on the server command line, once for the "stmt" combination, and once for the "mix" combination.

More than one combinations file may be applicable to a given test file. In this case, mtr will run the test for all possible combinations of the given combinations. A test that uses replication (three combinations as above) and innodb (two combinations - innodb and xtradb), will be run six times.

Sample Output

Typical mtr output looks like this

==============================================================================
TEST                                  WORKER RESULT   TIME (ms) or COMMENT
--------------------------------------------------------------------------
rpl.rpl_row_find_row_debug                [ skipped ]  Requires debug build
main-pbxt.connect                         [ skipped ]  No PBXT engine
main-pbxt.mysqlbinlog_row                 [ disabled ]  test expects a non-transactional engine
rpl.rpl_savepoint 'mix,xtradb'            w2 [ pass ]    238
rpl.rpl_stm_innodb 'innodb_plugin,row'    w1 [ skipped ]  Neither MIXED nor STATEMENT binlog format
binlog.binlog_sf 'stmt'                   w2 [ pass ]      7
unit.dbug                                 w2 [ pass ]      1
maria.small_blocksize                     w1 [ pass ]     23
sys_vars.autocommit_func3 'innodb_plugin' w1 [ pass ]      5
sys_vars.autocommit_func3 'xtradb'        w1 [ pass ]      6
main.ipv6                                 w1 [ pass ]    131
...

Every test is printed as "suitename.testname", and a suite name may include an overlay name (like in main-pbxt). After the test name, mtr prints combinations that were applied to this test, if any.

A similar syntax can be used on the mtr command line to specify what tests to run:

Plugin Support

The mtr driver has special support for MariaDB plugins.

First, on startup it copies or symlinks all dynamically-built plugins intovar/plugins. This allows one to have many plugins loaded at the same time. For example, one can load Federated and InnoDB engines together. Also, mtr creates environment variables for every plugin with the corresponding plugin name. For example, if the InnoDB engine was built, $HA_INNODB_SO will be set to ha_innodb.so (or ha_innodb.dll on Windows). And the test can safely use the corresponding environment variable on all platforms to refer to a plugin file; it will always have the correct platform-dependent extension.

Second, when combining server command-line options (which may come from many different sources) into one long list before starting mariadbd, mtr treats--plugin-load specially. Normal server semantics is to use the latest value of any particular option on the command line. If one starts the server with, for example, --port=2000 --port=3000, the server will use the last value for the port, that is 3000. To allow different .opt files to require different plugins, mtr goes through the assembled server command line, and joins all --plugin-load options into one. Additionally it removes all empty--plugin-load options. For example, suppose a test is affected by three.opt files which contain, respectively:

--plugin-load=$HA_INNODB_SO

--plugin-load=$AUTH_PAM_SO

--plugin-load=$HA_EXAMPLE_SO

...and, let's assume the Example engine was not built ($HA_EXAMPLE_SO is empty). Then the server will get:

--plugin-load=ha_innodb.so:auth_pam.so

instead of

--plugin-load=ha_innodb.so --plugin-load=auth_pam.so --plugin-load=

Third, to allow plugin sources to be simply copied into the plugin/ orstorage/ directories, and still not affect existing tests (even if new plugins are statically linked into the server), mtr automatically disables all optional plugins on server startup. A plugin is optional if it can be disabled with the corresponding --skip-XXX server command-line option. Mandatory plugins, like MyISAM or MEMORY, do not have --skip-XXX options (e.g. there is no --skip-myisam option). This mtr behavior means that no plugin, statically or dynamically built, has any effect on the server unless it was explicitly enabled. A convenient way to enable a given plugin XXX for specific tests is to create a have_XXX.opt file which contains the necessary command-line options, and a have_XXX.inc file which checks whether a plugin was loaded. Then any test that needs this plugin can source the have_XXX.inc file and have the plugin loaded automatically.

mtr communication procedure

mtr is first creating the server socket (master).

After that, workers are created using fork().

For each worker run_worker() function is called, which is executing the following:

• creates a new socket to connect to server_port obtained from the master

• initiate communication with the master using START command

• master sends first test from list of tests supplied by the user and immediately sends command TESTCASE to the worker

• worker gets command TESTCASE and processes test case, by calling run_testcase() function which starts(/restarts if needed) the server and sends TESTRESULT (in case of restart WARNINGS command is issued to the master in case some warnings/error logs are found)

• master accepts TESTRESULT command and run mtr_report_test() function which check does the test fail and also generates the new command TESTCASE if some new test case exist

• If there is no other test case master sends BYE command which gets accepted by the worker which is properly closing the connection.

_{This page is licensed: CC BY-SA / Gnu FDL}

When testing the S3 storage engine with the s3 test suite, mariadb-test-run needs access to Amazon S3 compatible storage.

The easiest way to achieve this is to install MinIO, an open source S3 compatible storage.

Here is a shell script that you can use to install MinIO with the right credentials for mariadb-test-run. This should work on most Linux systems as the binaries are statically linked. You can alternatively download MinIO binaries directly from here.

# Where to install the MinIO binaries and where to store the data
install=/my/local/minio
data=/tmp/shared

# Get the MinIO binaries. You can skip this test if you already have MinIO installed.
mkdir -p $install
wget https://dl.min.io/server/minio/release/linux-amd64/minio -O $install/minio
wget https://dl.min.io/client/mc/release/linux-amd64/mc -O $install/mc
chmod a+x $install/minio $install/mc

# Setup MinIO for usage with mariadb-test-run
MINIO_ACCESS_KEY=minio MINIO_SECRET_KEY=minioadmin $install/minio server $data 2>&1 &
$install/mc config host add local http://127.0.0.1:9000 minio minioadmin
$install/mc mb --ignore-existing local/storage-engine

Now you can run the S3 test suite:

cd "mysql-source-dir"/mariadb-test
./mariadb-test-run --suite=s3

If there is an issue while running the test suite, you can see the files created by MinIO with:

$install/mc ls -r local/storage-engine

or

ls $data/storage-engine

If you want to use MinIO with different credentials or you want to run the test against another S3 storage you ave to update the update the following files:

mariadb-test/suite/s3/my.cnf
mariadb-test/suite/s3/slave.cnf

_{This page is licensed: CC BY-SA / Gnu FDL}

The mariadb-test framework utilizes many other files that affect the testing process, in addition to test and result files.

disabled.def file

This file can be used to disable certain tests temporarily. For example, if one test fails and you are working on that, you may want to push the changeset that disables the test into the test suite so that other tests won't be disturbed by this failure.

The file contains test names and a comment (that should explain why the test was disabled), separated by a colon. Lines that start with a hash sign (#) are ignored. A typical disabled.def may look like this (note that a hash sign in the middle of a line does not start a comment):

# List of disabled tests
# test name : comment
rpl_redirect : Fails due to bug#49978
events_time_zone  : need to fix the timing

During testing, mtr will print disabled tests like this:

...
rpl.rpl_redirect              [ disabled ]  Fails due to bug#49978
rpl.events_time_zone          [ disabled ]  need to fix the timing
...

This file should be located in the suite directory.

suite.opt file

This file lists server options that will be added to the mariadbd command line for every test of this suite. It can refer to environment variables with the $NAME syntax. Shell meta-characters should be quoted. For example

--plugin-load=$AUTH_PAM_SO
--max-connections=40 --net_read_timeout=5
"--replicate-rewrite-db=test->rewrite"

Note that options may be put either on one line or on separate lines. It is a good idea to start an option name with the --loose- prefix if the server may or may not recognize the option depending on the configuration. An unknown option in the .opt file will stop the server from starting, and the test will be aborted.

This file should be located in the suite directory.

other *.opt files

For every test or include file somefile.test or somefile.inc, mtr will look for somefile.opt, somefile-master.opt and somefile-slave.opt. These files have exactly the same syntax as the suite.opt above. Options from these files will also be added to the server command line (all servers started for this test, only master, or only slave respectively) for all affected tests, for example, for all tests that include somefile.inc directly or indirectly.

A typical usage example is include/have_blackhole.inc andinclude/have_blackhole.opt. The latter contains the necessary command-line options to load the Blackhole storage engine, while the former verifies that the engine was really loaded. Any test that needs the Blackhole engine needs only to start from source include/have_blackhole.inc; and the engine will be automatically loaded for the test.

my.cnf file

This is not the my.cnf file that tests from this suite will use, but rather a template of it. It will be converted later to an actual my.cnf. If a suite contains no my.cnf template, a default template, — include/default_my.cnf — will be used. Or suite/rpl/my.cnf if the test includes master-slave.inc (it's one of the few bits of the old MySQLmysql-test-run magic that we have not removed yet). Typically a suite template will not contain a complete server configuration, but rather start from

!include include/default_my.cnf

and then add the necessary modifications.

The syntax of my.cnf template is the same of a normal my.cnf file, with a few extensions and assumptions. They are:

• For any group with the name [mysqld.N], where N is a number, mtr will start one mysqld process. Usually one needs to have only [mysqld.1] group, and [mysqld.2] group for replication tests.

• There can be groups with non-standard names ([foo], [bar], whatever), not used by mysqld. The suite.pm files (see below) may use them somehow.

• Values can refer to each other using the syntax @groupname.optionname — these references be expanded as needed. For example

[mysqld.2]
master-port= @mysqld.1.port

• it sets the value of the master-port in the [mysqld.2] group to the value of port in the [mysqld.1] group.

• An option name may start with a hash sign #. In the resulting my.cnf it will look like a comment, but it still can be referred to. For example:

[example]
#location = localhost:@mysqld.1.port
bar = server:@example.#location/data

• There is the [ENV] group. It sets values for the environment variables. For example

[ENV]
MASTER_MYPORT = @mysqld.1.port

• Also, one can refer to values of environment variables via this group:

[mysqld.1]
user = @ENV.LOGNAME

• There is the [OPT] group. It allows to invoke functions and generate values. Currently it contains only one option — @OPT.port. Every time this option is referred to in some other group in the my.cnf template, a new unique port number is generated. It will not match any other port number used by this test run. For example

[ENV]
SPHINXSEARCH_PORT = @OPT.port

This file should be located in the suite directory.

other *.cnf files

For every test file somefile.test (but for not included files) mtr will look for somefile.cnf file. If such a file exists, it will be used as a template instead of suite my.cnf or a default include/default_my.cnf templates.

combinations file

The combinations file defines few sets of alternative configurations, and every test in this suite will be run many times - once for every configuration. This can be used, for example, to run all replication tests in the rpl suite for all three binlog format modes (row, statement, and mixed). A corresponding combinations file would look as following:

[row]
binlog-format=row

[stmt]
binlog-format=statement

[mix]
binlog-format=mixed

It uses my.cnf file syntax, with groups (where group names define combination names) and options. But, despite the similarity, it is not amy.cnf template, and it cannot use the templating extentions. Instead, options from the combinations file are added to the server command line. In this regard, combination file is closer to suite.opt file. And just like it, combination file can use environment variables using the $NAME syntax.

Not all tests will necessarily run for all combinations. A particular test may require to be run only in one specific combination. For example, in replication, if a test can only be run with the row binlog format, it will have--binlog-format=row in one of the .opt files. In this case, mtr will notice that server command line already has an option that matches one of the combinations, and will skip all other combinations for this particular test.

The combinations file should be located in the suite directory.

other *.combinations files

Just like with the *.opt files, mtr will use somefile.combinations file for any somefile.test and somefile.inc that is used in testing. These files have exactly the same format as a suite combinations file.

This can cause many combination files affecting one test file (if a test includes two .inc files, and both of them have corresponding.combinations files). In this case, mtr will run the test for all combinations of combinations from both files. In MariaDB 5.5, for example,rpl_init.inc adds combinations for row/statement/mixed, andhave_innodb.inc adds combinations for innodb/xtradb. Thus any replication test that uses innodb will be run six times.

suite.pm file

This (optional) file is a perl module. It must declare a package that inherits from My::Suite.

This file must normally end with bless {} — that is it must return an object of that class. It can also return a string — in this case all tests in the suite will be skipped, with this string being printed as a reason (for example "PBXT engine was not compiled").

A suite class can define the following methods:

• config_files()

• is_default()

• list_cases()

• servers()

• skip_combinations()

• start_test()

A config_files() method returns a list of additional config files (besidesmy.cnf), that this suite needs to be created. For every file it specifies a function that will create it, when given a My::Config object. For example:

sub config_files {(
    'config.ini' => \&write_ini,
    'new.conf'   => \&do_new
)}

A servers() method returns a list of processes that needs to be started for this suite. A process is specified as a [regex, hash] pair. The regular expression must match a section in the my.cnf template (for example,qr/mysqld\./ corresponds to all mysqld processes), the hash contains these options:

sub servers {(
    qr/^foo$/ => { SORT => 200,  # start foo before mysqld
                   START => \&start_foo,
                   WAIT => \&wait_foo }
)}

See the sphinx suite for a working example.

A list_cases() method returns a complete list of tests for this suite. By default it will be the list of files that have .test extension, but without the extension. This list will be filtered by mtr, subject to different mtr options (--big-test, --start-from, etc), the suite object does not have to do it.

A start_test() method starts one test process, by default it will bemariadb-test. See the unit suite for a working example oflist_cases() and start_test() methods.

A skip_combinations() method returns a hash that maps file names (where combinations are defined) to a list of combinations that should be skipped. As a special case, it can disable a complete file by using a string instead of a hash. For example

sub skip_combinations {(
    'combinations' => [ 'mix', 'rpl' ],
    'inc/many.combinations' => [ 'a', 'bb', 'c' ],
    'windows.inc' => "Not on windows",
)}

The last line will cause all tests of this suite that include windows.inc to be skipped with the reason being "Not on windows".

An is_default() method returns 1 if this particular suite should be run by default, when the mariadb-test-run.pl script is run without explicitly specified test suites or test cases.

*.sh files

For every test file sometest.test mtr looks for sometest-master.sh andsometest-slave.sh. If either of these files is found, it will be run before the test itself.

*.require files

These files are obsolete. Do not use them anymore. If you need to skip a test use the skip command instead.

*.rdiff files

These files also define what the test result should be. But unlike *.result files, they contain a patch that should be applied to one result file to create a new result file. This is very useful when a result of some test in one combination differs slightly from the result of the same test, but in another combination. Or when a result of a test in an overlay differs from the test result in the overlayed suite.

It is quite difficult to edit .rdiff files to update them after the test file has changed. But luckily, it is never needed. When a test fails, mtr creates a .reject file. Having it, one can create .rdiff file as easy as (for example)

diff -u main/foo.result main/foo.reject > main/foo,comb.rdiff
or
diff -u main/foo.result main/foo,comb.reject > main/foo,comb.rdiff

Some example:

diff -u main/innodb_ext_key.result main/innodb_ext_key,off.reject > main/innodb_ext_key,off.rdiff

diff -u suite/sys_vars/r/sysvars_server_notembedded.result suite/sys_vars/r/sysvars_server_notembedded,32bit.reject > suite/sys_vars/r/sysvars_server_notembedded,32bit.rdiff

Note: This will also add a timestamp in the .rdiff file, so if you are submitting a patch you could remove it manually. If the same .rdiff file is used for multiple combinations, then it would be good to omit in the header that would identify the combination, to allow git to pack the repository better. Example:

--- testname.result
+++ testname.reject

Because a combination can be part of the .result or .rdiff file name, mtr has to look in many different places for a test result. For example, consider a test foo.test in the combination pair aa,bb, that is run in the overlay rty of the suite qwe, in other words, for the test that mtr prints as

qwe-rty.foo 'aa,bb'                     [ pass ]

For this test a result can be in

• either .rdiff or .result file

• either in the overlay "rty/" or in the overlayed suite "qwe/"

• with or without combinations in the file name (",a", ",b", ",a,b", or nothing)

which means any of the following 15 file names can be used:

1. rty/r/foo,aa,bb.result

2. rty/r/foo,aa,bb.rdiff

3. qwe/r/foo,aa,bb.result

4. qwe/r/foo,aa,bb.rdiff

5. rty/r/foo,aa.result

6. rty/r/foo,aa.rdiff

7. qwe/r/foo,aa.result

8. qwe/r/foo,aa.rdiff

9. rty/r/foo,bb.result

10. rty/r/foo,bb.rdiff

11. qwe/r/foo,bb.result

12. qwe/r/foo,bb.rdiff

13. rty/r/foo.result

14. rty/r/foo.rdiff

15. qwe/r/foo.result

They are listed, precisely, in the order of preference, and mtr will walk that list from top to bottom and the first file that is found will be used.

If this found file is a .rdiff, mtr continues walking down the list until the first .result file is found. A .rdiff is applied to that.result.

valgrind.supp file

This file defines valgrind suppressions, and it is used when mtr is started with a --valgrind option.

_{This page is licensed: CC BY-SA / Gnu FDL}

Syntax

./mariadb-test-run.pl [ OPTIONS ] [ TESTCASE ]

Where the test case can be specified as:testcase[.test] Runs the test case named 'testcase' from all suits

path-to-testcase
[suite.]testcase[,combination]

Examples

aliasmain.alias 'main' is the name of the suite for the 't' directory.

rpl.rpl_invoked_features,mix,xtradb_plugin
suite/rpl/t/rpl.rpl_invoked_features

Options

Options to Control What Engine/Variation to Run

Options to Control Directories to Use

Options to Control What Test Suites or Cases to Run

Options That Specify Ports

Options For Test Case Authoring

Options That Pass On Options

Options to Run Test On Running Server

Options For Debugging the Product

In mariadb-test-run.pl there is a concept of a "debugger". A "debugger" is a tool that mariadb-test-run.pl will execute instead of mariadbd. This tool will then start mariadbd and can control its execution as it wants. The following "debuggers" are supported:

Every "debugger" from the list above supports the following set of options (replace XXX below with a debugger name)

Every option from the above accepts an optional argument. It can be used to specify additional command line options to pass to the tool. Or additional commands that the tool will run on startup. Or both. Commands are separated from each other and from options with a semicolon. For example:

./mtr 1st --strace
./mtr 1st --client-rr=--chaos
./mtr 1st --manual-gdb='b mysql_parse;r'
./mtr 1st --boot-gdb='--quiet --tui;b mysql_parse;r'

Misc Debugging Related Options

Misc Options

_{This page is licensed: GPLv2}

Startup Option --connect-timeout

--connect-timeout=N

This can be used to set the MYSQL_OPT_CONNECT_TIMEOUT parameter of mysql_options, to change the number of seconds before an unsuccessful connection attempt times out.

Test Commands for Handling Warnings During Prepare Statements

• enable_prepare_warnings;

• disable_prepare_warnings;

Normally, when running with the prepared statement protocol with warnings enabled and executing a statement that returns a result set (like SELECT), warnings that occur during the execute phase are shown, but warnings that occur during the prepare phase are ''not'' shown. The reason for this is that some warnings are returned both during prepare and execute; if both copies of warnings were shown, then test cases would show different number of warnings between prepared statement execution and normal execution (where there is no prepare phase).

The enable_prepare_warnings command changes this so that warnings from both the prepare and execute phase are shown, regardless of whether the statement produces a result set in the execute phase. Thedisable_prepare_warnings command reverts to the default behaviour.

These commands only have effect when running with the prepared statement protocol (--ps-protocol) and with warnings enabled (enable_warnings). Furthermore, they only have effects for statements that return a result set (as for statements without result sets, warnings from are always shown when warnings are enabled).

The replace_regex command supports paired delimiters (like in perl, etc). If the first non-space character in the replace_regex argument is one of (, [, {, <, then the pattern should end with ), ], }, > accordingly. The replacement string can use its own pair of delimiters, not necessarily the same as the pattern. If the first non-space character in the replace_regex argument is not one of the above, then it should also separate the pattern and the replacement string and it should end the replacement string. Backslash can be used to escape the current terminating character as usual. The examples below demonstrate valid usage of replace_regex:

--replace_regex (/some/path)</another/path>
--replace_regex !/foo/bar!foobar!
--replace_regex {pat\}tern}/replace\/ment/i

Dumping "exec" output on errors only

Sometimes it is only interesting to see the output of a utility to stdout/stderr, if utility failed. In case of success , the output might be unpredictable, and contain timestamps, startup messages etc. mariadb-backup can be a good example of such utility.

mysqltest in MariaDB can helps in this situation. In the example below, the output of $XTRABACKUP is suppressed, however if exec fails, stdout and stderr both will be dumped , to aid diagnostics:

--disable_result_log
exec $XTRABACKUP  --param1 --param2  # Note, do not use output redirection here
--enable_result_log

_{This page is licensed: CC BY-SA / Gnu FDL}

Sometimes you need to work when your computer is busy running mariadb-test-run.pl. The mariadb-test-run.pl script allows you to stop it temporarily so you can use your computer and then restart the tests when you're ready.

There are two ways to enable this:

1. Command-line: The --stop-file and--stop-keep-alive options.

2. Environment Variables: If you are calling mariadb-test-run.pl indirectly (i.e from a script or program such as buildbot) you can setMTR_STOP_FILE and MTR_STOP_KEEP_ALIVE.

Keep Alive

If you plan on using this feature with other programs, such as buildbot, you should set the MTR_STOP_KEEP_ALIVE environment variable or the --stop-keep-alive command-line option with a value in seconds. This will make the script print messages to whatever program is calling mariadb-test-run.pl at the interval you set to prevent timeouts.

If you are calling mariadb-test-run.pl directly, you do not need to specify a timeout.

The mariadb-test-run Stop File

The stop file is a temporary file that you create on your system when you want to pause the execution of mariadb-test-run. When enabled via the command-line or environment variable options, mariadb-test-run will periodically check for the existence of the file and if it exists it will stop until the file is no longer present.

Examples

Command-line:

mariadb-test-run.pl --stop-file="/path/to/stop/file" --stop-keep-alive=120

Environment Variables:

export MTR_STOP_FILE="/path/to/stop/file"
export MTR_STOP_KEEP_ALIVE=120
mariadb-test-run.pl

_{This page is licensed: CC BY-SA / Gnu FDL}

The Debug Sync Facility allows placement of synchronization points in the server code by using the DEBUG_SYNC macro:

open_tables(...)

DEBUG_SYNC(thd, "after_open_tables");

lock_tables(...)

When activated, a sync point can

• Emit a signal and/or

• Wait for a signal

By default, all sync points are inactive. They do nothing (except to burn a couple of CPU cycles for checking if they are active).

A sync point becomes active when an action is requested for it. To do so, put a line like this in the test case file:

SET DEBUG_SYNC= 'after_open_tables SIGNAL opened WAIT_FOR flushed';

This activates the sync point'after_open_tables'. It requests it to emit the signal 'opened' and wait for another thread to emit the signal 'flushed' when the thread's execution runs through the sync point.

For every sync point there can be one action per thread only. Every thread can request multiple actions, but only one per sync point. In other words, a thread can activate multiple sync points.

Here is an example how to activate and use the sync points:

--connection conn1
SET DEBUG_SYNC= 'after_open_tables SIGNAL opened WAIT_FOR flushed';
send INSERT INTO t1 VALUES(1);
    --connection conn2
    SET DEBUG_SYNC= 'now WAIT_FOR opened';
    SET DEBUG_SYNC= 'after_abort_locks SIGNAL flushed';
    FLUSH TABLE t1;

When conn1 runs through theINSERT statement, it hits the sync point'after_open_tables'. It notices that it is active and executes its action. It emits the signal'opened' and waits for another thread to emit the signal 'flushed'.

conn2 waits immediately at the special sync point 'now' for another thread to emit the 'opened' signal.

A signal remains in effect until it is overwritten. Ifconn1 signals 'opened' beforeconn2 reaches 'now',conn2 will still find the'opened' signal. It does not wait in this case.

When conn2 reaches 'after_abort_locks', it signals 'flushed', which lets conn1 awake.

Normally the activation of a sync point is cleared when it has been executed. Sometimes it is necessary to keep the sync point active for another execution. You can add an execute count to the action:

SET DEBUG_SYNC= 'name SIGNAL sig EXECUTE 3';

This sets the signal point's activation counter to 3. Each execution decrements the counter. After the third execution the sync point becomes inactive.

One of the primary goals of this facility is to eliminate sleeps from the test suite. In most cases it should be possible to rewrite test cases so that they do not need to sleep. (But this facility cannot synchronize multiple processes.) However, to support test development, and as a last resort, sync point waiting times out. There is a default timeout, but it can be overridden:

SET DEBUG_SYNC= 'name WAIT_FOR sig TIMEOUT 10 EXECUTE 2';

TIMEOUT 0 is special: If the signal is not present, the wait times out immediately.

When a wait timed out (even on TIMEOUT 0), a warning is generated so that it shows up in the test result.

You can throw an error message and kill the query when a synchronization point is hit a certain number of times:

SET DEBUG_SYNC= 'name HIT_LIMIT 3';

Or combine it with signal and/or wait:

SET DEBUG_SYNC= 'name SIGNAL sig EXECUTE 2 HIT_LIMIT 3';

Here the first two hits emit the signal, the third hit returns the error message and kills the query.

For cases where you are not sure that an action is taken and thus cleared in any case, you can force to clear (deactivate) a sync point:

SET DEBUG_SYNC= 'name CLEAR';

If you want to clear all actions and clear the global signal, use:

SET DEBUG_SYNC= 'RESET';

This is the only way to reset the global signal to an empty string.

For testing of the facility itself you can execute a sync point just as if it had been hit:

SET DEBUG_SYNC= 'name TEST';

Formal Syntax

The string to "assign" to the DEBUG_SYNC variable can contain:

RESET |
<sync point name> TEST |
<sync point name> CLEAR |
<sync point name> {{SIGNAL <signal name> |
                   WAIT_FOR <signal name> [TIMEOUT <seconds>]}
                   [EXECUTE <count>] &| HIT_LIMIT <count>}

Here '&|' means 'and/or'. This means that one of the sections separated by '&|' must be present or both of them.

Activation/Deactivation

With a MariaDB for debug build, it can be enabled by a mysqld command line option:

--debug-sync-timeout[=default_wait_timeout_value_in_seconds]

'default_wait_timeout_value_in_seconds' is the default timeout for the WAIT_FOR action. If set to zero, the facility stays disabled.

The facility is enabled by default in the test suite, but can be disabled with:

mariadb-test-run.pl ... --debug-sync-timeout=0 ...

Likewise the default wait timeout can be set:

mariadb-test-run.pl ... --debug-sync-timeout=10 ...

The command line option influences the readable value of the debug_sync system variable.

• If the facility is not compiled in, the system variable does not exist.

• If --debug-sync-timeout=0 the value of the variable reads as "OFF".

• Otherwise the value reads as "ON - current signal: " followed by the current signal string, which can be empty.

The readable variable value is the same, regardless if read as a global or session value.

Setting the debug_sync system variable requires the 'SUPER' privilege. You can never read back the string that you assigned to the variable, unless you assign the value that the variable already has. But that would give a parse error. A syntactically correct string is parsed into a debug sync action and stored apart from the variable value.

Implementation

Pseudo code for a sync point:

#define DEBUG_SYNC(thd, sync_point_name)
        if (unlikely(opt_debug_sync_timeout))
          debug_sync(thd, STRING_WITH_LEN(sync_point_name))

The sync point performs a binary search in a sorted array of actions for this thread.

The SET DEBUG_SYNC statement adds a requested action to the array or overwrites an existing action for the same sync point. When it adds a new action, the array is sorted again.

A typical synchronization pattern

There are quite a few places in MariaDB and MySQL where we use a synchronization pattern like this:

mysql_mutex_lock(&mutex);
thd->enter_cond(&condition_variable, &mutex, new_message);
#if defined(ENABLE_DEBUG_SYNC)
if (!thd->killed && !end_of_wait_condition)
   DEBUG_SYNC(thd, "sync_point_name");
#endif
while (!thd->killed && !end_of_wait_condition)
  mysql_cond_wait(&condition_variable, &mutex);
thd->exit_cond(old_message);

Here are some explanations:

thd->enter_cond() is used to register the condition variable and the mutex in thd->mysys_var. This is done to allow the thread to be interrupted (killed) from its sleep. Another thread can find the condition variable to signal and mutex to use for synchronization in this thread's THD::mysys_var.

thd->enter_cond() requires the mutex to be acquired in advance.

thd->exit_cond() unregisters the condition variable and mutex and releases the mutex.

If you want to have a Debug Sync point with the wait, please place it behind enter_cond(). Only then you can safely decide, if the wait will be taken. Also you will haveTHD::proc_info correct when the sync point emits a signal. DEBUG_SYNC sets its own proc_info, but restores the previous one before releasing its internal mutex. As soon as another thread sees the signal, it does also see the proc_info from before entering the sync point. In this case it will be "new_message", which is associated with the wait that is to be synchronized.

In the example above, the wait condition is repeated before the sync point. This is done to skip the sync point, if no wait takes place. The sync point is before the loop (not inside the loop) to have it hit once only. It is possible that the condition variable is signaled multiple times without the wait condition to be true.

A bit off-topic: At some places, the loop is taken around the whole synchronization pattern:

while (!thd->killed && !end_of_wait_condition)
{
  mysql_mutex_lock(&mutex);
  thd->enter_cond(&condition_variable, &mutex, new_message);
  if (!thd->killed [&& !end_of_wait_condition])
  {
    [DEBUG_SYNC(thd, "sync_point_name");]
    mysql_cond_wait(&condition_variable, &mutex);
  }
  thd->exit_cond(old_message);
}

Note that it is important to repeat the test for thd->killed afterenter_cond(). Otherwise the killing thread may kill this thread after it tested thd->killed in the loop condition and before it registered the condition variable and mutex inenter_cond(). In this case, the killing thread does not know that this thread is going to wait on a condition variable. It would just set THD::killed. But if we would not test it again, we would go asleep though we are killed. If the killing thread would kill us when we are after the second test, but still before sleeping, we hold the mutex, which is registered in mysys_var. The killing thread would try to acquire the mutex before signaling the condition variable. Since the mutex is only released implicitly inmysql_cond_wait(), the signaling happens at the right place. We have a safe synchronization.

Co-work with the DBUG facility

When running the MariaDB test suite with the--debug-dbug command line option, the Debug Sync Facility writes trace messages to the DBUG trace. The following shell commands proved very useful in extracting relevant information:

egrep 'query:|debug_sync_exec:' mysql-test/var/log/mysqld.1.trace

It shows all executed SQL statements and all actions executed by synchronization points.

Sometimes it is also useful to see, which synchronization points have been run through (hit) with or without executing actions. Then add"|debug_sync_point:" to the egrep pattern.

Synchronizing DEBUG_SYNC Actions

Tests may need additional synchronization mechanisms betweenDEBUG_SYNC actions, because certain combinations of actions can result in lost signals. More specifically, once aSIGNAL action is issued, it is stored in a global variable for any waiting threads to determine if they are depending on that signal for continuing. However, if a subsequent action overwrites that variable before a waiting thread is able to check against it, the original signal is lost. Examples of actions which would change the variable state are anotherSIGNAL or a RESET. Therefore, before issuing these commands, the test writer should verify the previous signal has been acknowledged. The following code snippets show an example of a problematic pattern and a potential solution.

SET DEBUG_SYNC='now SIGNAL sig';
SET DEBUG_SYNC='RESET'; # Problematic because sig can be cleared before a waiting thread can acknowledge it

SET DEBUG_SYNC='now SIGNAL sig';

# Don't issue the RESET until we have proven the waiting thread has received the signal
let $wait_condition= select count(*)=0 from information_schema.processlist where state like "debug sync point%";
source include/wait_condition.inc;

SET DEBUG_SYNC='RESET'; # Now this is safe

_{This page is licensed: CC BY-SA / Gnu FDL}