Details

    Description

      innodb_zip.* and innodb.innodb-16k tests are failing on s390x arch with the following error message:

      ER_TOO_BIG_ROWSIZE (1118): Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.
      

      I am attaching the full log of the tests.

      Attachments

        1. mariadb-s390x-tests.log
          529 kB
          Danilo Spinella
        2. mariadb-s390x-build.txt
          6 kB
          Edward Stoever
        3. suse_skipped_tests.list.txt
          5 kB
          Edward Stoever

        Issue Links

          Activity

            I applied the following patch to simulate the patched s390x compressBound() in any cmake -DWITH_ZLIB=bundled build:

            diff --git a/zlib/compress.c b/zlib/compress.c
            index e2db404abf8..ab232aaaef6 100644
            --- a/zlib/compress.c
            +++ b/zlib/compress.c
            @@ -81,6 +81,28 @@ int ZEXPORT compress (dest, destLen, source, sourceLen)
             uLong ZEXPORT compressBound (sourceLen)
                 uLong sourceLen;
             {
            -    return sourceLen + (sourceLen >> 12) + (sourceLen >> 14) +
            -           (sourceLen >> 25) + 13;
            +
            +#define DFLTCC_BLOCK_HEADER_BITS 3
            +#define DFLTCC_HLITS_COUNT_BITS 5
            +#define DFLTCC_HDISTS_COUNT_BITS 5
            +#define DFLTCC_HCLENS_COUNT_BITS 4
            +#define DFLTCC_MAX_HCLENS 19
            +#define DFLTCC_HCLEN_BITS 3
            +#define DFLTCC_MAX_HLITS 286
            +#define DFLTCC_MAX_HDISTS 30
            +#define DFLTCC_MAX_HLIT_HDIST_BITS 7
            +#define DFLTCC_MAX_SYMBOL_BITS 16
            +#define DFLTCC_MAX_EOBS_BITS 15
            +#define DFLTCC_MAX_PADDING_BITS 7
            +#define DEFLATE_BOUND_COMPLEN(source_len) \
            +    ((DFLTCC_BLOCK_HEADER_BITS + \
            +      DFLTCC_HLITS_COUNT_BITS + \
            +      DFLTCC_HDISTS_COUNT_BITS + \
            +      DFLTCC_HCLENS_COUNT_BITS + \
            +      DFLTCC_MAX_HCLENS * DFLTCC_HCLEN_BITS + \
            +      (DFLTCC_MAX_HLITS + DFLTCC_MAX_HDISTS) * DFLTCC_MAX_HLIT_HDIST_BITS + \
            +      (source_len) * DFLTCC_MAX_SYMBOL_BITS + \
            +      DFLTCC_MAX_EOBS_BITS + \
            +      DFLTCC_MAX_PADDING_BITS) >> 3)
            +    return DEFLATE_BOUND_COMPLEN(sourceLen) + 6;
             }
            

            In the server error log I see the following:

            10.5 52b32c60c26b512ccf9b1233d7f54c4b56499df3

            2022-02-16 11:40:24 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
            

            In most failed tests, a CREATE TABLE statement fails with ER_TOO_BIG_ROWSIZE (1118). In innodb_zip.wl6347_comp_indx_stat, the observed data file sizes are larger. For the test innodb_zip.bug36169, a debug assertion (which is only enabled in debug builds) fails:

            10.5 52b32c60c26b512ccf9b1233d7f54c4b56499df3

            mariadbd: /mariadb/10.5m/storage/innobase/handler/ha_innodb.cc:12905: bool create_table_info_t::row_size_is_acceptable(const dict_index_t&, bool) const: Assertion `info.max_leaf_size != 0' failed.
            

            The full list of test failures is as follows:

            Completed: Failed 28/5574 tests, 99.50% were successful.
             
            Failing test(s): innodb.innodb-16k innodb_zip.page_size innodb_zip.index_large_prefix innodb_zip.prefix_index_liftedlimit innodb_zip.wl6347_comp_indx_stat innodb_zip.bug36172 innodb_zip.bug52745 innodb_zip.wl6344_compress_level innodb_zip.bug36169
            

            I will try to tweak all these tests so that they will pass with the normal compressBound() as well the weaker compressBound() guarantee that is associated with the s390x DFLTCC instruction.

            marko Marko Mäkelä added a comment - I applied the following patch to simulate the patched s390x compressBound() in any cmake -DWITH_ZLIB=bundled build: diff --git a/zlib/compress.c b/zlib/compress.c index e2db404abf8..ab232aaaef6 100644 --- a/zlib/compress.c +++ b/zlib/compress.c @@ -81,6 +81,28 @@ int ZEXPORT compress (dest, destLen, source, sourceLen) uLong ZEXPORT compressBound (sourceLen) uLong sourceLen; { - return sourceLen + (sourceLen >> 12) + (sourceLen >> 14) + - (sourceLen >> 25) + 13; + +#define DFLTCC_BLOCK_HEADER_BITS 3 +#define DFLTCC_HLITS_COUNT_BITS 5 +#define DFLTCC_HDISTS_COUNT_BITS 5 +#define DFLTCC_HCLENS_COUNT_BITS 4 +#define DFLTCC_MAX_HCLENS 19 +#define DFLTCC_HCLEN_BITS 3 +#define DFLTCC_MAX_HLITS 286 +#define DFLTCC_MAX_HDISTS 30 +#define DFLTCC_MAX_HLIT_HDIST_BITS 7 +#define DFLTCC_MAX_SYMBOL_BITS 16 +#define DFLTCC_MAX_EOBS_BITS 15 +#define DFLTCC_MAX_PADDING_BITS 7 +#define DEFLATE_BOUND_COMPLEN(source_len) \ + ((DFLTCC_BLOCK_HEADER_BITS + \ + DFLTCC_HLITS_COUNT_BITS + \ + DFLTCC_HDISTS_COUNT_BITS + \ + DFLTCC_HCLENS_COUNT_BITS + \ + DFLTCC_MAX_HCLENS * DFLTCC_HCLEN_BITS + \ + (DFLTCC_MAX_HLITS + DFLTCC_MAX_HDISTS) * DFLTCC_MAX_HLIT_HDIST_BITS + \ + (source_len) * DFLTCC_MAX_SYMBOL_BITS + \ + DFLTCC_MAX_EOBS_BITS + \ + DFLTCC_MAX_PADDING_BITS) >> 3) + return DEFLATE_BOUND_COMPLEN(sourceLen) + 6; } In the server error log I see the following: 10.5 52b32c60c26b512ccf9b1233d7f54c4b56499df3 2022-02-16 11:40:24 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 In most failed tests, a CREATE TABLE statement fails with ER_TOO_BIG_ROWSIZE (1118). In innodb_zip.wl6347_comp_indx_stat , the observed data file sizes are larger. For the test innodb_zip.bug36169 , a debug assertion (which is only enabled in debug builds) fails: 10.5 52b32c60c26b512ccf9b1233d7f54c4b56499df3 mariadbd: /mariadb/10.5m/storage/innobase/handler/ha_innodb.cc:12905: bool create_table_info_t::row_size_is_acceptable(const dict_index_t&, bool) const: Assertion `info.max_leaf_size != 0' failed. The full list of test failures is as follows: Completed: Failed 28/5574 tests, 99.50% were successful.   Failing test(s): innodb.innodb-16k innodb_zip.page_size innodb_zip.index_large_prefix innodb_zip.prefix_index_liftedlimit innodb_zip.wl6347_comp_indx_stat innodb_zip.bug36172 innodb_zip.bug52745 innodb_zip.wl6344_compress_level innodb_zip.bug36169 I will try to tweak all these tests so that they will pass with the normal compressBound() as well the weaker compressBound() guarantee that is associated with the s390x DFLTCC instruction.

            The following version of the function generates the same AMD64 code for me:

            uLong ZEXPORT compressBound (sourceLen)
                uLong sourceLen;
            {
                return (sourceLen * 16 + 2308) / 8 + 6;
            }
            

            marko Marko Mäkelä added a comment - The following version of the function generates the same AMD64 code for me: uLong ZEXPORT compressBound (sourceLen) uLong sourceLen; { return (sourceLen * 16 + 2308) / 8 + 6; }

            danyspin97, for some time, the results from my test push are available at https://buildbot.mariadb.org/#/grid?branch=st-10.5-MDEV-27634
            For reference, I am quoting the names of all failed tests on the s390x builders that have completed so far:

            s390x-rhel-8

            archive.archive
            connect.zip
            main.column_compression
            main.column_compression_rpl
            main.column_compression_rpl
            main.column_compression_rpl
            main.func_compress
            main.func_math
            main.mysqlbinlog_row_compressed
            main.mysqlbinlog_stmt_compressed

            s390x-sles-15

            archive.archive
            connect.zip
            main.column_compression
            main.column_compression_rpl
            main.column_compression_rpl
            main.column_compression_rpl
            main.func_compress
            main.mysqlbinlog_row_compressed
            main.mysqlbinlog_stmt_compressed
            perfschema.show_aggregate

            s390x-ubuntu-2004

            main.column_compression
            main.func_math

            Analysis

            The builders s390x-rhel-8-rpm-autobake, s390x-sles-15-rpm-autobake had not completed as of this writing. I would assume that they will fare in a similar way to the non-autobake builds.

            The test perfschema.show_aggregate is failing very often on various platforms, including AMD64. The other failures look like they may be directly related to the zlib version.

            As you can see, the Docker container that pretends to be Ubuntu 20.04 had fewer failing tests; perhaps they are not applying that s390x DFLTCC patch? The failure of the test main.column_compression might be explained by the bug MDEV-24797; I suggest that if it is so, you’d post any analysis there.

            None of the remaining tests should be related to InnoDB and this ticket.

            I plan to push the fix to the 10.2 branch and merge from there to later-version branches.

            marko Marko Mäkelä added a comment - danyspin97 , for some time, the results from my test push are available at https://buildbot.mariadb.org/#/grid?branch=st-10.5-MDEV-27634 For reference, I am quoting the names of all failed tests on the s390x builders that have completed so far: s390x-rhel-8 archive.archive connect.zip main.column_compression main.column_compression_rpl main.column_compression_rpl main.column_compression_rpl main.func_compress main.func_math main.mysqlbinlog_row_compressed main.mysqlbinlog_stmt_compressed s390x-sles-15 archive.archive connect.zip main.column_compression main.column_compression_rpl main.column_compression_rpl main.column_compression_rpl main.func_compress main.mysqlbinlog_row_compressed main.mysqlbinlog_stmt_compressed perfschema.show_aggregate s390x-ubuntu-2004 main.column_compression main.func_math Analysis The builders s390x-rhel-8-rpm-autobake, s390x-sles-15-rpm-autobake had not completed as of this writing. I would assume that they will fare in a similar way to the non-autobake builds. The test perfschema.show_aggregate is failing very often on various platforms, including AMD64. The other failures look like they may be directly related to the zlib version. As you can see, the Docker container that pretends to be Ubuntu 20.04 had fewer failing tests; perhaps they are not applying that s390x DFLTCC patch? The failure of the test main.column_compression might be explained by the bug MDEV-24797 ; I suggest that if it is so, you’d post any analysis there. None of the remaining tests should be related to InnoDB and this ticket. I plan to push the fix to the 10.2 branch and merge from there to later-version branches.

            Thank you @Marko Mäkelä for the help and the fix. Regarding the other tests, I also think that they are not related to s390x DFLTCC patch as they are currently succeeding for us. The main.func_math is currently failing in some configurations and could be related to MDEV-26645.

            danyspin97 Danilo Spinella added a comment - Thank you @Marko Mäkelä for the help and the fix. Regarding the other tests, I also think that they are not related to s390x DFLTCC patch as they are currently succeeding for us. The main.func_math is currently failing in some configurations and could be related to MDEV-26645 .

            The test case innodb.row_size_error_log_warnings_3 that was added along with the fix of MDEV-20194 failed to take the modified compressBound() into account. I have now fixed that in 10.4 (where we do not have any s390x builders at the moment) and merged the change to 10.5 and 10.6.

            marko Marko Mäkelä added a comment - The test case innodb.row_size_error_log_warnings_3 that was added along with the fix of MDEV-20194 failed to take the modified compressBound() into account. I have now fixed that in 10.4 (where we do not have any s390x builders at the moment) and merged the change to 10.5 and 10.6 .

            People

              marko Marko Mäkelä
              danyspin97 Danilo Spinella
              Votes:
              0 Vote for this issue
              Watchers:
              4 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.