Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-8841

innodb_zip.innodb-create-options fails in buildbot

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.5
    • Fix Version/s: 5.5.46
    • Component/s: Tests
    • Labels:
      None

      Description

      http://buildbot.askmonty.org/buildbot/builders/work-amd64-valgrind/builds/7594/steps/test/logs/stdio

      innodb_zip.innodb-create-options 'xtradb' w1 [ fail ]  Found warnings/errors in server log file!
              Test ended at 2015-09-07 18:21:20
      line
      150907 18:20:53 [ERROR] mysqld: Table './mysql/proc' is marked as crashed and should be repaired
      150907 18:20:53 [Warning] Checking table:   './mysql/proc'
      ^ Found warnings in /mnt/data/buildot/maria-slave/work-opensuse-amd64/build/mysql-test/var/1/log/mysqld.1.err
      ok
      

      It fails on a valgrind build, but without valgrind errors.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              elenst Elena Stepanova added a comment - - edited

              The reason of the problem is this:
              tests test1, test2, test3 are run by the same worker. All tests have the same config, so the server does not get restarted between them.
              test1 creates a function or a procedure and then drops it.
              test2 as a part of its flow kills the server and restarts it.
              test3 is an ordinary test which does not do anything specific.

              So, test1 does the proper cleanup, but mysql.proc remains open.
              test2 crashes the server, so mysql.proc does not get properly closed; but since the test does not do anything with the table, the error remains unnoticed and only appears in the error log on the post-test check; if the test were the last one before the server restart, there would have been a warning (errors during shutdown), but there is no shutdown, hence no warnings;
              thus the error in the log is attributed to the next test in line.

              In our case, test1 is innodb.innodb_notembedded (but it can really be any test which does something with a system table), test2 is innodb.xa_recovery, and test3 is innodb_zip.innodb-create-options which is reported to be failed, but again it could be any other test as well.

              perl ./mtr --noreorder innodb.innodb_notembedded,innodb_plugin innodb.xa_recovery,innodb_plugin innodb_zip.innodb-create-options,innodb_plugin
              
              worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
              innodb.innodb_notembedded 'innodb_plugin' [ pass ]    485
              innodb.xa_recovery 'innodb_plugin'       [ pass ]   7131
              
              
              innodb_zip.innodb-create-options 'innodb_plugin' [ fail ]  Found warnings/errors in server log file!
                      Test ended at 2015-09-24 21:19:43
              line
              150924 21:19:06 [ERROR] mysqld: Table './mysql/proc' is marked as crashed and should be repaired
              150924 21:19:06 [Warning] Checking table:   './mysql/proc'
              ^ Found warnings in /home/elenst/git/5.5/mysql-test/var/log/mysqld.1.err
              ok
              

              Thus, the only suitable place to fix it is in xa_recovery. The least intrusive solution that I see is to add FLUSH TABLES at the beginning of the test. It does not contradict the test logic, but remains previous influences.

              Show
              elenst Elena Stepanova added a comment - - edited The reason of the problem is this: tests test1, test2, test3 are run by the same worker. All tests have the same config, so the server does not get restarted between them. test1 creates a function or a procedure and then drops it. test2 as a part of its flow kills the server and restarts it. test3 is an ordinary test which does not do anything specific. So, test1 does the proper cleanup, but mysql.proc remains open. test2 crashes the server, so mysql.proc does not get properly closed; but since the test does not do anything with the table, the error remains unnoticed and only appears in the error log on the post-test check; if the test were the last one before the server restart, there would have been a warning (errors during shutdown), but there is no shutdown, hence no warnings; thus the error in the log is attributed to the next test in line. In our case, test1 is innodb.innodb_notembedded (but it can really be any test which does something with a system table), test2 is innodb.xa_recovery, and test3 is innodb_zip.innodb-create-options which is reported to be failed, but again it could be any other test as well. perl ./mtr --noreorder innodb.innodb_notembedded,innodb_plugin innodb.xa_recovery,innodb_plugin innodb_zip.innodb-create-options,innodb_plugin worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019 innodb.innodb_notembedded 'innodb_plugin' [ pass ] 485 innodb.xa_recovery 'innodb_plugin' [ pass ] 7131 innodb_zip.innodb-create-options 'innodb_plugin' [ fail ] Found warnings/errors in server log file! Test ended at 2015-09-24 21:19:43 line 150924 21:19:06 [ERROR] mysqld: Table './mysql/proc' is marked as crashed and should be repaired 150924 21:19:06 [Warning] Checking table: './mysql/proc' ^ Found warnings in /home/elenst/git/5.5/mysql-test/var/log/mysqld.1.err ok Thus, the only suitable place to fix it is in xa_recovery. The least intrusive solution that I see is to add FLUSH TABLES at the beginning of the test. It does not contradict the test logic, but remains previous influences.
              Show
              elenst Elena Stepanova added a comment - https://github.com/MariaDB/server/commit/dca4ab92b8e32ae1abe54666cf2313d94d5804a4

                People

                • Assignee:
                  elenst Elena Stepanova
                  Reporter:
                  elenst Elena Stepanova
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: