I presume the problem might be related to MDEV-5891

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.

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?

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

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

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.

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

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.

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