Valgrind

I applied some changes up to 10.6. Later major version branches may require further tests to be disabled.

I would like to know why there is an extra 2 minute timeout for valgrind during kill. I have not noticed that on my system don't understand why that would happen in buildbot either (for short running tests).

In my experience, it is easier to use valgrind than ASAN and MSAM and it does uncover issues that nether of the above does by themself.

The test disabled by this MDEV are:

• innodb.innodb-index-online
• innodb.innodb_buffer_pool_dump_abort_loads
• innodb innodb_bug53290
• innodb.alter_copy
• innodb.autoinc_persist
• innodb.innodb-stats-initialize-failure
• innodb.innodb-stats-sample
• innodb.innodb-trim
• innodb.innodb_bug30423
• innodb.log_corruption
• innodb.log_file
• innodb.log_file_name
• innodb.read_only_recover_committed
• innodb.recovery_shutdown
• innodb.undo_truncate
• innodb.alter_missing_tablespace
• innodb_fts.innodb_fts_plugin
• innodb.ibuf_not_empty
• innodb.innodb-get-fk
• innodb.missing_tablespaces
• innodb.table_flags
• innodb.xa_recovery
• mariabackup/log_page_corruption
• rpl.rpl_semi_sync_shutdown_await_ack
• rpl.rpl_gtid_stop_start
• rpl.rpl_mdev12179
• federated.federatedx_create_handlers
• sys_vars.innodb_flush_method_func
• sys_vars.innodb_buffer_pool_dump_at_shutdown_basic
• main.update_use_source
• main.func_json_notembedded
• main.rowid_filter_innodb_debug
• main.mysql_upgrade
• main.plugin_auth
• main.log_slow
• All tests that include master-slave.inc !!!!

It is of course correct to disable slow running tests, but we need to
ensure that tests that are running differently under valgrind are not
just disabled as the timing differences that valgrind causes can show
bugs we don't know of.

What I dislike is that we disabled all master-slave test with valgrind
with the change to master-slave.inc! This means that nothing in the 'rpl'
suite is tested with valgrind.
What is worse, is that we now an warning for each test in rpl when
we try to run them with the --valgrind flag!

This is not right as there is many issues in the slave code that
should be tested also with valgrind!

The tests that restart InnoDB and I disabled under Valgrind would typically fail either due to a forcibly killed shutdown, or a timeout during recovery. InnoDB recovery is multi-threaded, because data pages will be read asynchronously and log will be applied as part of invoking the read completion callback function. This may have become much slower under Valgrind due to MDEV-21351 and other performance improvements in MariaDB Server 10.5.

I observed sporadic failures of a large number of replication tests, apparently related to server shutdown timing out. Some trouble was around the STOP SLAVE command. I did not diagnose the cause of those failures in detail, but I could believe that it was related to unfair scheduling.

What I did not disable was tests that use DEBUG_SYNC. As I noted in MDBF-406, those can fail sporadically too. The failure probability is considerably lower than with the tests that I disabled for Valgrind.

I do not see any value in a builder that is constantly failing. Any new failures would typically be ignored by all developers, because the builder is reliably failing all the time. Before this effort by me, this actually was the case with the Valgrind builder. I think that it is better to remove extremely frequent failures, because currently the cross-reference does not allow filtering out a particular builder.