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

mariadb-server: fil_load_single_table_tablespace(): mysqld killed by SIGABRT

Details

    Description

      Hello,

      I got here following issue:
      RHBZ 1468115
      RHBZ 1468255

      For both I have cool retrace informations like this, URLs can be found right before 1st comment in the bugzillas.

      On one hand, the workaround could be easy - disable the problematic plugin by deafult.
      On the other hand, the SIGABRT code shows, there is most probabbly issue in the code.

      Attachments

        1. akonadi and stuff
          3 kB
          Michal Schorm

        Issue Links

          duplicates

          Bug - A problem which impairs or prevents the functions of the product. MDEV-13499 Backing up table that "doesn't exist in engine" cause crash in mariabackup when using encryption

          • Major - Major loss of function.
          • Closed
          is caused by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-9282 Debian: the Lintian complains about "shlib-calls-exit" in ha_innodb.so

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 16 older comments
            jplindst Jan Lindström (Inactive) added a comment -

            I rather not do the required cleanup in GA-release so I will let it crash on this case and fix only the mariabackup case.

            jplindst Jan Lindström (Inactive) added a comment - I rather not do the required cleanup in GA-release so I will let it crash on this case and fix only the mariabackup case.
            jplindst Jan Lindström (Inactive) added a comment -

            Closing as works as designed. Workaround is to use innodb-force-recovery=1.

            jplindst Jan Lindström (Inactive) added a comment - Closing as works as designed. Workaround is to use innodb-force-recovery=1.
            mschorm Michal Schorm added a comment -

            Thanks for the investigation.

            Just to clarify: "Starting with MariaDB 10.2.2, we would allow the server to start up without InnoDB."
            means that if the startup encounter some error, it won't call exit() or abort(), but tries to start without InnoDB?
            ( Or does it mean only that it is possible to start wihtout InnoDB? )

            mschorm Michal Schorm added a comment - Thanks for the investigation. Just to clarify: "Starting with MariaDB 10.2.2, we would allow the server to start up without InnoDB." means that if the startup encounter some error, it won't call exit() or abort(), but tries to start without InnoDB? ( Or does it mean only that it is possible to start wihtout InnoDB? )
            marko Marko Mäkelä added a comment -

            This bug was fixed by me in WL#7142 (MySQL 5.7.5). The InnoDB crash recovery was changed so that if the redo log refers to files that are missing, InnoDB will propagate the error to the caller of innobase_init(). These changes were included in MariaDB 10.2.2.

            In MySQL 5.7, missing files would still abort the server startup unless innodb_force_recovery is specified, because InnoDB cannot be disabled there. In MariaDB, InnoDB can be disabled, and a failure to start up InnoDB will not prevent the rest of the server from starting up. Related to this, I fixed many things related to shutdown after aborted InnoDB startup in MariaDB 10.2.

            The bug is not feasible to fix in earlier MariaDB versions. Backporting the redo log format change is clearly out of the question, and the InnoDB code base has changed very much between MariaDB 10.1 and 10.2.

            The related bug in Mariabackup was fixed in MDEV-13499.

            marko Marko Mäkelä added a comment - This bug was fixed by me in WL#7142 (MySQL 5.7.5). The InnoDB crash recovery was changed so that if the redo log refers to files that are missing, InnoDB will propagate the error to the caller of innobase_init() . These changes were included in MariaDB 10.2.2 . In MySQL 5.7, missing files would still abort the server startup unless innodb_force_recovery is specified, because InnoDB cannot be disabled there. In MariaDB, InnoDB can be disabled, and a failure to start up InnoDB will not prevent the rest of the server from starting up. Related to this, I fixed many things related to shutdown after aborted InnoDB startup in MariaDB 10.2. The bug is not feasible to fix in earlier MariaDB versions. Backporting the redo log format change is clearly out of the question, and the InnoDB code base has changed very much between MariaDB 10.1 and 10.2. The related bug in Mariabackup was fixed in MDEV-13499 .
            mschorm Michal Schorm added a comment -

            I understand.
            Closing Fedora bug reports as "fixed in next release; won't be fixed in F26".

            Thanks for the investigation!

            mschorm Michal Schorm added a comment - I understand. Closing Fedora bug reports as "fixed in next release; won't be fixed in F26". Thanks for the investigation!

            People

              marko Marko Mäkelä
              mschorm Michal Schorm
              Votes:
              0 Vote for this issue
              Watchers:
              6 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.