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

encryption.innodb_encrypt_temporary_tables failed in buildbot with wrong result

Details

    Description

      http://buildbot.askmonty.org/buildbot/builders/kvm-asan/builds/1730

      10.2 60c790d6f40dcb8e86734d1106c58869

      encryption.innodb_encrypt_temporary_tables 'cbc,innodb' w1 [ fail ]
              Test ended at 2019-07-22 11:11:28
       
      CURRENT_TEST: encryption.innodb_encrypt_temporary_tables
      --- /home/buildbot/buildbot/build/mariadb-10.2.26/mysql-test/suite/encryption/r/innodb_encrypt_temporary_tables.result	2019-07-22 08:31:21.000000000 -0400
      +++ /home/buildbot/buildbot/build/mariadb-10.2.26/mysql-test/suite/encryption/r/innodb_encrypt_temporary_tables.reject	2019-07-22 11:11:28.235518198 -0400
      @@ -12,7 +12,7 @@
       SELECT variable_value > @old_encrypted FROM information_schema.global_status
       WHERE variable_name = 'innodb_encryption_n_temp_blocks_encrypted';
       variable_value > @old_encrypted
      -1
      +0
       SELECT variable_value > @old_decrypted FROM information_schema.global_status
       WHERE variable_name = 'innodb_encryption_n_temp_blocks_decrypted';
       variable_value > @old_decrypted
       
      mysqltest: Result content mismatch
      

      Attachments

        Issue Links

          Activity

            alice Alice Sherepa added a comment - the same on 10.4 http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-centos6-x86/builds/1380/steps/mtr/logs/stdio

            I think that the test is inaccurate. Maybe the page replacement is not always guaranteed, and we should insert more data to guarantee page eviction from the buffer pool?

            One thing that the test is definitely missing is a read of the table t2. It reads from t1 after hopefully evicting some of its pages by populating another table t2.

            The buffer pool size is at the minimum (5MiB). That would host at most 320 pages at the default innodb_page_size=16k.

            The test is inserting 2×8192 rows into 3 tables. The leaf-level record payload size is about 6+6+7+200+200 and 6+6+7+100+200+200 bytes (419 and 519 bytes). That is 4,251,648 bytes for the larger table. With the page header and trailer overhead, maybe it should exceed the 5,242,880 bytes?

            I was able to repeat this problem very easily when I was diagnosing MDEV-23304. So, I should be able to stabilize this test.

            marko Marko Mäkelä added a comment - I think that the test is inaccurate. Maybe the page replacement is not always guaranteed, and we should insert more data to guarantee page eviction from the buffer pool? One thing that the test is definitely missing is a read of the table t2 . It reads from t1 after hopefully evicting some of its pages by populating another table t2 . The buffer pool size is at the minimum (5MiB). That would host at most 320 pages at the default innodb_page_size=16k . The test is inserting 2×8192 rows into 3 tables. The leaf-level record payload size is about 6+6+7+200+200 and 6+6+7+100+200+200 bytes (419 and 519 bytes). That is 4,251,648 bytes for the larger table. With the page header and trailer overhead, maybe it should exceed the 5,242,880 bytes? I was able to repeat this problem very easily when I was diagnosing MDEV-23304 . So, I should be able to stabilize this test.

            I pushed a fixup to 10.2 that I hope will make the failure disappear. But, I was unable to reproduce this failure in my environment today. Therefore, I am not closing this bug yet.

            marko Marko Mäkelä added a comment - I pushed a fixup to 10.2 that I hope will make the failure disappear . But, I was unable to reproduce this failure in my environment today. Therefore, I am not closing this bug yet.

            This test still occasionally fails. If I ignore all the crashes on POWER due to a Linux kernel bug (MDEV-30728) there have been a few failures like this:

            bb-10.4-release c4143f909528e3fab0677a28631d10389354c491

            encryption.innodb_encrypt_temporary_tables 'cbc,innodb,strict_full_crc32' w1 [ fail ]
                    Test ended at 2023-10-30 13:33:43
             
            CURRENT_TEST: encryption.innodb_encrypt_temporary_tables
            --- /home/buildbot/buildbot/build/mariadb-10.4.32/mysql-test/suite/encryption/r/innodb_encrypt_temporary_tables.result	2023-10-30 12:36:19.000000000 +0000
            +++ /home/buildbot/buildbot/build/mariadb-10.4.32/mysql-test/suite/encryption/r/innodb_encrypt_temporary_tables.reject	2023-10-30 13:33:40.257265525 +0000
            @@ -15,7 +15,7 @@
             SELECT variable_value > @old_encrypted FROM information_schema.global_status
             WHERE variable_name = 'innodb_encryption_n_temp_blocks_encrypted';
             variable_value > @old_encrypted
            -1
            +0
             SELECT variable_value > @old_decrypted FROM information_schema.global_status
             WHERE variable_name = 'innodb_encryption_n_temp_blocks_decrypted';
             variable_value > @old_decrypted
             
            mysqltest: Result content mismatch
            

            I recently found out that information_schema.global_status.variable_value is a character string, not an integer. An explicit cast to integer is needed if we want integer comparison semantics instead of character string (9<10 but '9'>'10').

            marko Marko Mäkelä added a comment - This test still occasionally fails. If I ignore all the crashes on POWER due to a Linux kernel bug ( MDEV-30728 ) there have been a few failures like this: bb-10.4-release c4143f909528e3fab0677a28631d10389354c491 encryption.innodb_encrypt_temporary_tables 'cbc,innodb,strict_full_crc32' w1 [ fail ] Test ended at 2023-10-30 13:33:43   CURRENT_TEST: encryption.innodb_encrypt_temporary_tables --- /home/buildbot/buildbot/build/mariadb-10.4.32/mysql-test/suite/encryption/r/innodb_encrypt_temporary_tables.result 2023-10-30 12:36:19.000000000 +0000 +++ /home/buildbot/buildbot/build/mariadb-10.4.32/mysql-test/suite/encryption/r/innodb_encrypt_temporary_tables.reject 2023-10-30 13:33:40.257265525 +0000 @@ -15,7 +15,7 @@ SELECT variable_value > @old_encrypted FROM information_schema.global_status WHERE variable_name = 'innodb_encryption_n_temp_blocks_encrypted'; variable_value > @old_encrypted -1 +0 SELECT variable_value > @old_decrypted FROM information_schema.global_status WHERE variable_name = 'innodb_encryption_n_temp_blocks_decrypted'; variable_value > @old_decrypted   mysqltest: Result content mismatch I recently found out that information_schema.global_status.variable_value is a character string, not an integer. An explicit cast to integer is needed if we want integer comparison semantics instead of character string (9<10 but '9'>'10').

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.