Our solution follows a model which maintains most of the database manipulation logic in stored procedures.

When I upgraded from 10.2.9 to 10.2.11 I immediately got a failure in existing established code. This code also continues to function on 10.1.28 without problem.

I have prepared a database dump and a script which create a repeatable error.

to avoid shipping all of the code in the database I cut down the number of procedures shipped to a minimum, and the problem is now occurring in a different procedure so it looks like a general error rather than something that is specific to a partiiuclar error in our code.

I dont want to load up the database dump onto a public web site so can I provide that separately when this bug is picked up.

I have attached below the server.cnf file, the error log associated with the current repeatable crash plus a couple of other error logs from previous tests, plus the script to generate this problem.

To recreate:

• create a database ipswichdb;
• create a user ipswichdba and essentially grant them super user administrator status to the database.
• mysql -u ipswichdb -p <ip_2018_01_02_togo.sql
• mysql -u ipswichdba -p <ip_error_gen.sql

the error files below I generated by using first deleting my current error log and then doing a systemctl restart mariadb after loading the database and before running the test script.

Also I actually run the test script in Heidi, but I get the same effect whether its hedi or a more complex java app that I am running that normally triggers the problem.

Using the 2.1.2 java connector