Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL)
-
None
Description
I was playing with https://clang.llvm.org/docs/SanitizerCoverage.html and it looks like some changes to mtr will be needed for it to be useful.
What I did was basically the following:
mkdir build
|
cd build
|
cmake -DWITH_ASAN=ON -DCMAKE_C_FLAGS=-fsanitize-coverage=trace-pc-guard -DCMAKE_CXX_FLAGS=-fsanitize-coverage=trace-pc-guard -DCMAKE_C_COMPILER=clang-14 -DCMAKE_CXX_COMPILER=clang++-14 ..
|
cmake --build .
|
cd mysql-test
|
ASAN_OPTIONS=abort_on_error=1:coverage=1 ./mtr --big-test --parallel=auto --force --max-test-fail=0
|
The following patch will be needed to not trip on SanitizerCoverage messages:
diff --git a/mysql-test/mariadb-test-run.pl b/mysql-test/mariadb-test-run.pl
|
index 1449d3ecb9a..11ca745e415 100755
|
--- a/mysql-test/mariadb-test-run.pl
|
+++ b/mysql-test/mariadb-test-run.pl
|
@@ -4335,7 +4335,7 @@ sub extract_warning_lines ($$) {
|
qr/missing DBUG_RETURN/,
|
qr/Attempting backtrace/,
|
qr/Assertion .* failed/,
|
- qr/Sanitizer/,
|
+ qr/Sanitizer[^C]/,
|
qr/runtime error:/,
|
);
|
# These are taken from the include/mtr_warnings.sql global suppression |
I think that we might want to selectively disable the code coverage instrumentation for some process invocations. Here is an example of a bogus failure:
CURRENT_TEST: federated.federated_debug
|
--- /mariadb/10.6/mysql-test/suite/federated/federated_debug.result 2020-07-14 16:19:22.470932869 +0300
|
+++ /mariadb/10.6/mysql-test/suite/federated/federated_debug.reject 2022-04-22 16:11:06.069240849 +0300
|
@@ -17,6 +17,7 @@
|
a
|
1
|
# Start a asynchronous reload
|
+SanitizerCoverage: ./mariadb-admin.3518872.sancov: 780 PCs written
|
# Wait for tables to be closed
|
# Ensure that the server didn't crash
|
SELECT * FROM t1;
|
|
|
mysqltest: Result length mismatch
|
An alternative might be to implement a coverage reporting interface (in mysys?) that would not output such messages, but only write *.sancov files.
The .sancov files are potentially better than gcov’s .gcda and .gcno files, because one file will be written per process, not per source file. Therefore, in parallel mtr runs there should be no risk of corrupting the files by the concurrent execution of multiple copies of the instrumented program. For a 10.6 test run, I got 53 test failures:
|
10.6 fae0ccad6ec391bf85c39070f784589d48e11951 with MDEV-15250 changes |
Failing test(s): encryption.tempfiles encryption.innodb_first_page federated.federated_debug main.mysqlbinlog main.mysqldump binlog.binlog_mysqlbinlog_suppress_O_TMPFILE binlog.binlog_mysqlbinlog_row maria.maria-gis-recovery maria.maria-recovery2 main.ssl_7937 maria.maria-recovery maria.maria-recovery3 main.mysql_tzinfo_to_sql_symlink main.ssl_system_ca main.ssl_8k_key main.plugin_auth_qa_2 main.plugin_auth_qa_3 main.plugin_auth_qa_1 type_test.type_test_mysql maria.maria-recovery-big main.mysqldump-no-binlog main.ssl_crl main.binary_to_hex main.mysqlslap main.mysql_comments main.mysql_not_windows main.mysql_protocols main.perror main.mysqladmin main.mysqld--defaults-file maria.maria-recovery-rtree-ft main.mysqld--help-aria main.mysqltest maria.maria-recovery-bitmap main.connect_debug main.ssl_ca maria.maria-autozerofill main.myisampack type_inet.type_inet6_mysql maria.maria_showlog_error maria.maria-no-logging main.ssl_crl_clients main.mysql main.mysql-bug41486 main.mysql-bug45236 maria.maria-purge client.mariadb-conv-utf16 client.mariadb-conv
|
Disabling some ASAN instrumentation could lead to a faster execution. (A custom coverage reporting interface would not need this.)
ASAN_OPTIONS=coverage=1:detect_leaks=0:poison_heap=0 ./mtr innodb.instant_alter_debug,dynamic
|
sancov-14 -symbolize var/mysqld.1/data/mariadbd.*.sancov ../sql/mariadbd > mariadbd.symcov
|
coverage-report-server.py --symcov mariadbd.symcov --srcpath /path/to/source
|
The Python script starts a server by default at http://localhost:8001 where the coverage result can be browsed.
Unfortunately, it looks like similar to gcov (see MDEV-20694), some code that was covered by the test is indicated as not covered (marked up in red color).
Perhaps it would help to implement a custom coverage callback that would also be invoked by some signal handlers, so that we will get coverage reports for cases where the process was killed during the test.
Attachments
Issue Links
- relates to
-
-
- Open
-