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

    • Bug
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • 10.0.10
    • 10.5, 10.6
    • None
    • 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 :/

      Attachments

        Issue Links

          is blocked by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-5891 Assertion `! ((size_t)orig == (size_t)-1 && (size_t)dest == (size_t)-1)' failed in open_query::edges_cursor::fetch_row(..) with InnoDB backing table

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 4 older comments
            andymc73 Andrew McDonnell added a comment -

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

            andymc73 Andrew McDonnell added a comment - Are you able to post the table definition and insert statements leading up?
            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.

            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.
            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...

            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...
            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.

            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.
            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

            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

              Unassigned Unassigned
              pprkut Heinz Wiesinger
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.