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

InnoDB: Trying to read page … which is outside the tablespace bounds

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Cannot Reproduce
    • 10.4.32
    • N/A
    • Windows 11 64B, XAMPP v3.3.0, MySQL server

    Description

      Cannot open MySQL from XAMPP Control Panel. Working fine a few days before, no changes made of any kind. This is what I see on XAMPP after I start Apache, then MySQL:
      Error: MySQL shutdown unexpectedly
      This maybe be due to a blocked port, missing dependencies, improper privileges, a crash, or a shutdown by another method.
      mysql_error.log says:
      2024-12-27 14:45:20 0 [ERROR] [FATAL] InnoDB: Trying to read page number 6933 in space 0, space name innodb_system, which is outside the tablespace bounds. Byte offset 0, len 16384Please check that the configuration matches the InnoDB system tablespace location (ibdata files)
      241227 14:45:20 [ERROR] mysqld got exception 0x80000003 ;
      Sorry, we probably made a mistake, and this is a bug.

      I am also providing my "my.ini", just in case.

      Attachments

        1. mysql_error.log
          4 kB
        2. xampp1.jpg
          xampp1.jpg
          147 kB
        3. my.ini
          6 kB

        Issue Links

          Activity

            rhp03 Rafael Huijon added a comment -

            Hi Sergie;
            I am sorry, but I am not as techy as you might think. I created a Slack account, but it says that I am not part of the team. I don't if I am supposed to do anything with your post. Thanks.

            rhp03 Rafael Huijon added a comment - Hi Sergie; I am sorry, but I am not as techy as you might think. I created a Slack account, but it says that I am not part of the team. I don't if I am supposed to do anything with your post. Thanks.

            rhp03, no, you don't. You've created the issue in the wrong project (MDBF) and I moved it where it should be (MDEV) so that we could find it. You don't need to do anything about this

            serg Sergei Golubchik added a comment - rhp03 , no, you don't. You've created the issue in the wrong project (MDBF) and I moved it where it should be (MDEV) so that we could find it. You don't need to do anything about this

            mysql_error.log contains the following:

            mariadb-10.4.32

            2024-12-27 14:45:20 0 [ERROR] [FATAL] InnoDB: Trying to read page number 6933 in space 0, space name innodb_system, which is outside the tablespace bounds. Byte offset 0, len 16384Please check that the configuration matches the InnoDB system tablespace location (ibdata files)
            

            This intentional crash on an out-of-bounds read was removed in this merge of this change, in MariaDB Server 10.6.5. The foundation for that had been laid in MDEV-13542.

            It is hard to say what could cause an out-of-bounds access. I can offer a guess. Even though we reproduced MDEV-30671 and MDEV-31355 only when using innodb_undo_tablespaces>1 and innodb_undo_log_truncate=ON, I suspect that these bugs affect also the innodb_undo_tablespaces=0 case, but are harder to hit. The scenario would be that an old transaction tried to access an old version of a record, but the undo log page that contained the history had been freed prematurely and reused for something else. Then, as part of interpreting something as an undo log record, InnoDB would try to access an out-of-bounds page. This is just one possible guess.

            If the server had crashed in the past, it is possible that some corruption was inflicted due to a crash recovery bug. I do not remember the bug numbers anymore, but there should be one or two reported cases of backup or recovery failing before MariaDB Server 10.5. When I redesigned the redo log record format in MDEV-12353, I noticed a few broken cases, at least related to SPATIAL INDEX, but I don’t think that it can be the problem here.

            The page flushing and checkpoint logic was greatly simplified in MariaDB Server 10.5. I suspect that some hard-to-reproduce recovery or mariabackup failures in 10.4 could have disappeared thanks to that.

            I think that your best option is to start the server with innodb_force_recovery=2 and use mysqldump to back up the database, and then load the dump into MariaDB Server 10.6.20 or 10.11.10 or later. If the 10.4 server would crash during the execution of mysqldump, then you should try innodb_force_recovery=3. Be aware that this may result in an inconsistent dump, because it would hard-wire the transaction isolation level to READ UNCOMMITTED.

            MariaDB Server 10.4 is not supported anymore. The last release in that series was 10.4.34 in May 2024.

            marko Marko Mäkelä added a comment - mysql_error.log contains the following: mariadb-10.4.32 2024-12-27 14:45:20 0 [ERROR] [FATAL] InnoDB: Trying to read page number 6933 in space 0, space name innodb_system, which is outside the tablespace bounds. Byte offset 0, len 16384Please check that the configuration matches the InnoDB system tablespace location (ibdata files) This intentional crash on an out-of-bounds read was removed in this merge of this change , in MariaDB Server 10.6.5. The foundation for that had been laid in MDEV-13542 . It is hard to say what could cause an out-of-bounds access. I can offer a guess. Even though we reproduced MDEV-30671 and MDEV-31355 only when using innodb_undo_tablespaces>1 and innodb_undo_log_truncate=ON , I suspect that these bugs affect also the innodb_undo_tablespaces=0 case, but are harder to hit. The scenario would be that an old transaction tried to access an old version of a record, but the undo log page that contained the history had been freed prematurely and reused for something else. Then, as part of interpreting something as an undo log record, InnoDB would try to access an out-of-bounds page. This is just one possible guess. If the server had crashed in the past, it is possible that some corruption was inflicted due to a crash recovery bug. I do not remember the bug numbers anymore, but there should be one or two reported cases of backup or recovery failing before MariaDB Server 10.5. When I redesigned the redo log record format in MDEV-12353 , I noticed a few broken cases, at least related to SPATIAL INDEX , but I don’t think that it can be the problem here. The page flushing and checkpoint logic was greatly simplified in MariaDB Server 10.5. I suspect that some hard-to-reproduce recovery or mariabackup failures in 10.4 could have disappeared thanks to that. I think that your best option is to start the server with innodb_force_recovery=2 and use mysqldump to back up the database, and then load the dump into MariaDB Server 10.6.20 or 10.11.10 or later. If the 10.4 server would crash during the execution of mysqldump , then you should try innodb_force_recovery=3 . Be aware that this may result in an inconsistent dump, because it would hard-wire the transaction isolation level to READ UNCOMMITTED . MariaDB Server 10.4 is not supported anymore. The last release in that series was 10.4.34 in May 2024.

            I see that all XAMPP downloads that are offered on https://www.apachefriends.org/download.html are based on MariaDB Server 10.4.32 or 10.4.28. I think that we need to encourage them to offer more up to date versions.

            marko Marko Mäkelä added a comment - I see that all XAMPP downloads that are offered on https://www.apachefriends.org/download.html are based on MariaDB Server 10.4.32 or 10.4.28. I think that we need to encourage them to offer more up to date versions.

            Could you try setting innodb_force_recovery and say here whether it helped to recover from a corrupted tablespace?

            See https://mariadb.com/kb/en/innodb-recovery-modes/

            serg Sergei Golubchik added a comment - Could you try setting innodb_force_recovery and say here whether it helped to recover from a corrupted tablespace? See https://mariadb.com/kb/en/innodb-recovery-modes/

            got a reply per email

            I went to a previous version and re-install XAMPP and WP, so I am working normally.

            serg Sergei Golubchik added a comment - got a reply per email I went to a previous version and re-install XAMPP and WP, so I am working normally.

            There is an open ticket https://github.com/ApacheFriends/xampp-build/issues/17 that requests XAMPP to switch to a supported version of MariaDB Server.

            marko Marko Mäkelä added a comment - There is an open ticket https://github.com/ApacheFriends/xampp-build/issues/17 that requests XAMPP to switch to a supported version of MariaDB Server.

            People

              Unassigned Unassigned
              rhp03 Rafael Huijon
              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.