[MDEV-5988] Running mysqlcheck -A --auto-repair on OQGraph InnoDB backing table causes crashes on subsequent OQGRAPH queries. Created: 2014-03-31  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.10
Fix Version/s: 10.4, 10.5, 10.6

Type: Bug Priority: Minor
Reporter: Heinz Wiesinger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: oqgraph
Environment:

CentOS 6

Attachments: File crash.log     File crash_myisam.log    
Issue Links:
Blocks
is blocked by MDEV-5891 Assertion `! ((size_t)orig == (size_t... Closed

 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 :/

 Comments   
Comment by Elena Stepanova [ 2014-03-31 ]

I presume the problem might be related to MDEV-5891

Comment by Heinz Wiesinger [ 2014-03-31 ]

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.

Comment by Elena Stepanova [ 2014-03-31 ]

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?

Comment by Heinz Wiesinger [ 2014-03-31 ]

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

Comment by Andrew McDonnell [ 2014-04-02 ]

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

Comment by Heinz Wiesinger [ 2014-04-02 ]

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.

Comment by Andrew McDonnell [ 2014-04-08 ]

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

Comment by Heinz Wiesinger [ 2014-04-10 ]

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.

Comment by Andrew McDonnell [ 2014-04-11 ]

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

Generated at Thu Feb 08 07:08:32 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.