| Bug #91022 | audit_null.audit_plugin_bugs test always failing | ||
|---|---|---|---|
| Submitted: | 25 May 2018 7:48 | Modified: | 25 May 2018 8:14 |
| Reporter: | Laurynas Biveinis (OCA) | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Server: Tests | Severity: | S3 (Non-critical) |
| Version: | 8.0.11 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | audit api, mtr | ||
[25 May 2018 8:14]
MySQL Verification Team
Hello Laurynas, Thank you for the report and feedback! Thanks, Umesh
[6 Sep 2018 7:33]
Przemysław Skibiński
Fix for audit_null.audit_plugin_bugs and 8.0.12
Attachment: audit_plugin_bugs_8.0.12.patch (text/x-patch), 1.57 KiB.
[24 Oct 2018 9:29]
Erlend Dahl
Przemysław, thank you for your patch. In order for us to accept the patch you need to sign Oracle Contributor Agreement (OCA) as described in the "Contributions" section of this bug report. -Erlend Dahl (Release Manager MySQL 8.0)
[24 Oct 2018 9:49]
Przemysław Skibiński
Fix for audit_null.audit_plugin_bugs with 8.0.12 (*) I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it.
Contribution: audit_plugin_bugs_8.0.12.patch (text/x-patch), 1.57 KiB.
[19 Nov 2018 7:54]
Tatjana Nuernberg
Hi Przemysław, Thank you very kindly for your patch! Just to keep you in the loop: The test suite generally checks for regressions etc., so when we see a failure such as this, it is reasonable to start with the assumption that a regression happened in the code, and that the test case documents the correct behaviour. Your patch seems based on this assumption. In this particular case however, policy changed (which you had no way of knowing), so we'll likely update the test-case instead of the code. (Specifically, error messages logged in the error log now have error-codes >= 10,000, and error messages sent to the client have codes < 10,000. So far, so good. However, there is a special case (that applies here): when the server tries to send feedback to a client, but no client is actually attached (as can be the case during startup/bootstrap situations), we divert the message to the error-log instead (in a wrapper message explaining what happened and giving the original error-code, and with a >= 10,000 error-code so we can validly send it to the error-log). It is because of this behaviour that the message changed (by being wrapped in the explanatory message), and the test's pattern no longer matched it.)
Description: audit_null.audit_plugin_bugs w4 [ fail ] Test ended at 2018-05-24 11:47:29 CURRENT_TEST: audit_null.audit_plugin_bugs --- /mnt/workspace/mysql-5.7-param/BUILD_TYPE/debug/Host/min-trusty-x64/mysql-test/suite/audit_null/r/audit_plugin_bugs.result 2018-05-24 13:15:27.630084999 +0300 +++ /mnt/workspace/mysql-5.7-param/BUILD_TYPE/debug/Host/min-trusty-x64/build/mysql-test/var/4/log/audit_plugin_bugs.reject 2018-05-24 14:47:29.244729000 +0300 @@ -5,10 +5,10 @@ # Shutdown the server # Load the plugin at startup and abort on STARTUP with default message # Search for default abort message -Pattern "\[ERROR\] \[[^]]*\] \[[^]]*\] Aborted by Audit API \(\'MYSQL_AUDIT_SERVER_STARTUP_STARTUP\'.1\)\." found +Pattern "\[ERROR\] \[[^]]*\] \[[^]]*\] Aborted by Audit API \(\'MYSQL_AUDIT_SERVER_STARTUP_STARTUP\'.1\)\." not found # Load the plugin at startup and abort on STARTUP event with custom message # Search for custom abort message -Pattern "\[ERROR\] \[[^]]*\] \[[^]]*\] Abort message custom" found +Pattern "\[ERROR\] \[[^]]*\] \[[^]]*\] Abort message custom" not found # Startup the server # # Bug #22136709: INFINITE RECURSION BY CALLING MY_MESSAGE FROM mysqltest: Result content mismatch How to repeat: ./mtr --debug-server --suite=audit_null audit_plugin_bugs