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

NULL passed to String::eq, SEGV, server crash, regression in 10.4

Details

    Description

      On upgrade from MariaDB 10.3 to 10.4, merge_key_fields() calls eq_by_collation(), Item_const_eq() and finally String::eq(NULL, <String>, <charset>), and thus SEGV. MariaDB 10.3 and below are not affected. The bug is reliably reproduced, but hard to narrow down, as the same query will execute twice correctly, and crash the server on the third go.

      The client in this case is "mythbackend," the server component to the MythTV DVR. It communicates with MariaDB via QT, using prepared statements. The statement that causes the crash is always the same:

      SELECT recordid, category, (category = ?) AS catmatch, (category = ?) AS typematch FROM record WHERE type = ? AND (category = ? OR category = ? OR category = 'Default') ORDER BY catmatch DESC, typematch DESC

      The mythbackend program reports the DB error as follows:

      Query was:
      SELECT recordid, category, (category = ?) AS catmatch, (category = ?) AS typematch FROM record WHERE type = ? AND (category = ? OR category = ? OR category = 'Default') ORDER BY catmatch DESC, typematch DESC
      Bindings were:
      :CAT1="", :CAT2="", :CATTYPE1="", :CATTYPE2="", :TEMPLATE=11
      Driver error was:
      QMYSQL3: Unable to execute statement
      Database error was:
      MySQL server has gone away

      As mentioned, this query has been run twice before in the same session, successfully. Immediately prior to the third (and failing) execution is a "smoking gun" of sorts, this log entry in mythbackend's log file:

      QMYSQLResult::cleanup: unable to free statement handle

      Immediately afterwards, the SELECT statement is prepared, executed, and crashes. This suggests that the "Close stmt" operation from the immediately preceding prepared statement returned an error. I upgraded QT from 5.12.2 to 5.12.4 (and also MythTV), but the result was the same.

      I am attaching the MariaDB error.log and general.log showing the SQL executed and the resulting crash. Also attaching the log generated by mythbackend/QT, showing its activity. I recompiled MariaDB with CMAKE_BUILD_TYPE=Debug, and used that with GDB to obtain a more useful backtrace, also attached.

      Attachments

        1. error-3.log
          6 kB
        2. general-3.log
          9 kB
        3. mariadb-backtrace-1.txt
          5 kB
        4. mythbackend-3.log
          13 kB

        Issue Links

          Activity

            I think that's true, the fix didn't make it to the release and was pushed very soon afterwards. bar, could you please double-check and fix the version accordingly?

            elenst Elena Stepanova added a comment - I think that's true, the fix didn't make it to the release and was pushed very soon afterwards. bar , could you please double-check and fix the version accordingly?

            This ticket should be reopened as this issue appear unsolved in stable.

            Louis Louis Tim Larsen added a comment - This ticket should be reopened as this issue appear unsolved in stable.

            This bug was fixed in 10.4.14.

            The original fix version 10.4.13 was wrong. i pushed the fix after 10.4.13 was cloned off.

            bar Alexander Barkov added a comment - This bug was fixed in 10.4.14. The original fix version 10.4.13 was wrong. i pushed the fix after 10.4.13 was cloned off.
            ktk Kris Karas added a comment -

            This is the OP, just chiming in that the fix from Alexander has been tested (against 10.5.5) and appears to work fine.

            Today I upgraded 5 instances running 10.4 to 10.5, and figured I'd give it a whirl on the MythTV server still running 10.3.24. Before the fix, reproducing the bug was trivial when changing channels while watching "Live TV" on the MythTV application. After the fix/upgrade, to test, I changed channels with abandon, and could not cause MariaDB to crash. (I did manage to crash the MythTV frontend a few times by asking it to change channels too frequently and to a station with a poor signal, but that's not MariaDB's fault.)

            Interestingly, I noticed many more connection-aborted errors with 10.5 than with 10.3 during my testing today. The log output from mariadbd was peppered with, for example:
            2020-08-13 2:29:22 385 [Warning] Aborted connection 385 to db: 'unconnected' user: 'unauthenticated' host: 'oakdale' (This connection closed normally without authentication)
            2020-08-13 2:32:29 406 [Warning] Aborted connection 406 to db: 'mythconverg' user: 'mythtv' host: 'springdale' (Got an error reading communication packets)
            I assume this is a logging enhancement in 10.5 (or 10.4) and not a new issue. In any case, it does hint at a problem in MythTV's connection management code.

            ktk Kris Karas added a comment - This is the OP, just chiming in that the fix from Alexander has been tested (against 10.5.5) and appears to work fine. Today I upgraded 5 instances running 10.4 to 10.5, and figured I'd give it a whirl on the MythTV server still running 10.3.24. Before the fix, reproducing the bug was trivial when changing channels while watching "Live TV" on the MythTV application. After the fix/upgrade, to test, I changed channels with abandon, and could not cause MariaDB to crash. (I did manage to crash the MythTV frontend a few times by asking it to change channels too frequently and to a station with a poor signal, but that's not MariaDB's fault.) Interestingly, I noticed many more connection-aborted errors with 10.5 than with 10.3 during my testing today. The log output from mariadbd was peppered with, for example: 2020-08-13 2:29:22 385 [Warning] Aborted connection 385 to db: 'unconnected' user: 'unauthenticated' host: 'oakdale' (This connection closed normally without authentication) 2020-08-13 2:32:29 406 [Warning] Aborted connection 406 to db: 'mythconverg' user: 'mythtv' host: 'springdale' (Got an error reading communication packets) I assume this is a logging enhancement in 10.5 (or 10.4) and not a new issue. In any case, it does hint at a problem in MythTV's connection management code.

            Hi ktk, thanks for confirming that the bugs has gone. Sorry for the confusion with the initial wrong fixVersion.

            bar Alexander Barkov added a comment - Hi ktk , thanks for confirming that the bugs has gone. Sorry for the confusion with the initial wrong fixVersion.

            People

              bar Alexander Barkov
              ktk Kris Karas
              Votes:
              2 Vote for this issue
              Watchers:
              9 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.