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

Running mysqlcheck -A --auto-repair on OQGraph InnoDB backing table causes crashes on subsequent OQGRAPH queries.

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 10.0.10
    • Fix Version/s: 10.0
    • Component/s: None
    • Labels:
    • Environment:
      CentOS 6

      Description

      I have the weird situation that querying dijkstras shortest path on an OQGraph table, which has an InnoDB backing table sometimes results in a crash. Stacktrace attached.

      This is the query I run:

      SELECT * FROM oq_graph WHERE latch='dijkstras' AND origid=0;

      The weird thing is that after the server automatically restarts after the crash, the query works. Then I run mysqlcheck on the entire database and after running it the query causes the crash again. So I somehow ended up in an endless loop here :/

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              elenst Elena Stepanova added a comment - - edited

              I presume the problem might be related to MDEV-5891

              Show
              elenst Elena Stepanova added a comment - - edited I presume the problem might be related to MDEV-5891
              Hide
              pprkut Heinz Wiesinger added a comment -

              Doesn't look like it's got anything to do with InnoDB after all. I converted the table to MyISAM and I'm still getting the same behavior.

              Show
              pprkut Heinz Wiesinger added a comment - Doesn't look like it's got anything to do with InnoDB after all. I converted the table to MyISAM and I'm still getting the same behavior.
              Hide
              elenst Elena Stepanova added a comment -

              What exactly are you getting with MyISAM?
              The error log that you attached contains an InnoDB-specific assertion failure, you cannot possibly get it with MyISAM, so there must be a different error now?

              Show
              elenst Elena Stepanova added a comment - What exactly are you getting with MyISAM? The error log that you attached contains an InnoDB-specific assertion failure, you cannot possibly get it with MyISAM, so there must be a different error now?
              Hide
              pprkut Heinz Wiesinger added a comment -

              Attaching the log of the crash with myisam. It looked close enough to the original crash backtrace to me, but maybe it isn't.

              Show
              pprkut Heinz Wiesinger added a comment - Attaching the log of the crash with myisam. It looked close enough to the original crash backtrace to me, but maybe it isn't.
              Hide
              andymc73 Andrew McDonnell added a comment -

              Are you able to post the table definition and insert statements leading up?

              Show
              andymc73 Andrew McDonnell added a comment - Are you able to post the table definition and insert statements leading up?
              Hide
              pprkut Heinz Wiesinger added a comment -

              Table definition is the same as the one I posted in MDEV-5996. Insert statements may prove a bit difficult as a full dump of the data is a) subjectively rather big (50MB) and b) may contain sensitive data. I can try removing the sensitive parts, which would also dramatically reduce size, and see if the crash then still happens.

              Show
              pprkut Heinz Wiesinger added a comment - Table definition is the same as the one I posted in MDEV-5996 . Insert statements may prove a bit difficult as a full dump of the data is a) subjectively rather big (50MB) and b) may contain sensitive data. I can try removing the sensitive parts, which would also dramatically reduce size, and see if the crash then still happens.
              Hide
              andymc73 Andrew McDonnell added a comment -

              Are you able to repeat using a debug build instead? These stack traces are C++ mangled function names and no line numbers which is somewhat more tricky to work out where the crash happened.

              They do both look quite different as well...

              Show
              andymc73 Andrew McDonnell added a comment - Are you able to repeat using a debug build instead? These stack traces are C++ mangled function names and no line numbers which is somewhat more tricky to work out where the crash happened. They do both look quite different as well...
              Hide
              pprkut Heinz Wiesinger added a comment -

              I managed to reproduce this very easily with the examples on https://mariadb.com/kb/en/oqgraph-examples/ .
              Create a new database and add the 'oq_backing' table (I added ENGINE=InnoDB to the create table statement). Insert the example data and then add the 'oq_graph' table.
              Run "mysqlcheck -A --auto-repair" and do not restart the server afterwards. Run 'SELECT * FROM oq_graph WHERE latch='dijkstras' AND origid=1;' and the server should crash.

              I could unfortunately not reproduce the crash with MyISAM like this, but it happened under the same circumstances.

              Show
              pprkut Heinz Wiesinger added a comment - I managed to reproduce this very easily with the examples on https://mariadb.com/kb/en/oqgraph-examples/ . Create a new database and add the 'oq_backing' table (I added ENGINE=InnoDB to the create table statement). Insert the example data and then add the 'oq_graph' table. Run "mysqlcheck -A --auto-repair" and do not restart the server afterwards. Run 'SELECT * FROM oq_graph WHERE latch='dijkstras' AND origid=1;' and the server should crash. I could unfortunately not reproduce the crash with MyISAM like this, but it happened under the same circumstances.
              Hide
              andymc73 Andrew McDonnell added a comment -

              WIthout having dove into the detail yet, based on 'do not restart the server' my prediction is that that that tool does stuff to memory that oqgraph may be (incorrectly) hanging onto or not told to release (not listening for some notification from the server).

              Will try and repeat this next week

              Show
              andymc73 Andrew McDonnell added a comment - WIthout having dove into the detail yet, based on 'do not restart the server' my prediction is that that that tool does stuff to memory that oqgraph may be (incorrectly) hanging onto or not told to release (not listening for some notification from the server). Will try and repeat this next week

                People

                • Assignee:
                  andymc73 Andrew McDonnell
                  Reporter:
                  pprkut Heinz Wiesinger
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated: